Problemas comuns e resoluções de desempenho de aplicações de tela

Pode criar aplicações de tela utilizando uma matriz diversa de origens de dados. Escolha a origem de dados e o conector, com base nas necessidades e cenários do negócio para os quais a aplicação foi concebida. Para aplicações empresariais, o Microsoft Dataverse é a origem de dados recomendada porque fornece vários benefícios de desempenho. Em aplicações com algumas transações, pode ir para quaisquer outras origens de dados disponíveis no ambiente.

Para considerações de desempenho de uma aplicação, pense no número de utilizadores que irão utilizar a aplicação quando esta tiver sido publicada; o volume de transações de criação, obtenção, atualização e eliminação (CRUD); o tipo de interações de dados; o acesso geográfico; e os tipos de dispositivos que os utilizadores têm.

Neste artigo, vai aprender sobre alguns dos problemas de desempenho mais comuns que podem fazer com que aplicações de tela sejam executadas lentamente, e como resolvê-los. Estas informações vão ajudá-lo a melhorar o desempenho da aplicação com o seu plano de negócios e crescimento em mente.

Começaremos com alguns problemas comuns de desempenho que ocorrem, independentemente do conector a ser usado. Nas secções posteriores, ficará a conhecer problemas de desempenho e resoluções específicas para vários conectores.

Antes de começar, certifique-se de que compreende as fases de execução de aplicações de tela e o fluxo de chamadas de dados. Além disso, leia Origens comuns de desempenho lento para uma aplicação de tela para conhecer armadilhas comuns que pode evitar durante a conceção ou atualização de aplicações de tela.

Grandes conjuntos de dados a carregar lentamente em diferentes plataformas

O desempenho de uma aplicação pode variar ao carregar grandes conjuntos de dados em diferentes plataformas, como iOS ou Android. Esta variação ocorre devido a diferentes limitações de pedidos de rede em cada plataforma. Por exemplo, o número de pedidos de rede simultâneos permitidos pode divergir por plataforma. Esta diferença pode ter um grande impacto no tempo de carregamento de dados para grandes conjuntos de dados.

Recomendamos que carregue apenas os dados necessários para apresentar imediatamente no ecrã. Para outros dados, pagine e coloque em cache os seus dados. Mais informações: Dicas e melhores práticas para melhorar o desempenho de aplicações de tela

Demasiadas colunas obtidas

Recomendamos que selecione apenas as colunas necessárias para a aplicação. Adicionar mais (ou todas) as colunas da origem de dados transfere todos os dados nas colunas. Esta ação resulta num elevado número de chamadas de rede gerais e, portanto, numa utilização de memória elevada no dispositivo cliente. Este problema pode afetar ainda mais os utilizadores com dispositivos móveis se a largura de banda da rede for limitada, ou se um dispositivo tiver memória limitada ou um processador legado.

Por exemplo, se utilizar o Dataverse como a origem de dados para a sua aplicação, certifique-se de que ativou a funcionalidade seleção de colunas explícita. Esta funcionalidade permite que o Power Apps restrinja a obtenção de dados apenas para as colunas utilizadas na aplicação.

Para ativar a funcionalidade de seleção explícita de colunas na aplicação de tela, aceda a Definições>Funcionalidades futuras>Pré-visualização e, em seguida, ative o comutador de Seleção explícita de colunas.

Browsers não suportados ou legados

Os utilizadores que utilizam browsers não suportados ou legados, podem ter problemas de desempenho. Certifique-se de que os utilizadores utilizam apenas os browsers suportados para executar aplicações de tela.

Desempenho lento devido à distância geográfica

A localização geográfica do ambiente e a distância da origem de dados dos utilizadores pode afetar o desempenho.

Recomendamos que o seu ambiente esteja localizado perto dos utilizadores. Embora o Power Apps utilize a Rede de Entrega de Conteúdos do Azure para conteúdo, as chamadas de dados ainda obtêm os dados da origem de dados. Uma origem de dados localizada noutro local geográfico pode afetar negativamente o desempenho da aplicação.

As distâncias de localização geográficas excessivas afetam o desempenho de diferentes formas, tais como latência, débito reduzido, menor largura de banda ou perda de pacotes.

Lista de permissões não configurada

Certifique-se de que os URLs de serviço necessários não foram bloqueados ou que foram adicionados à lista de permissões da sua firewall. Para uma lista completa de todos os URLs de serviço que têm de ser autorizados para o Power Apps, vá a Serviços obrigatórios.

Utilização de funções não delegáveis e limites de linha de dados inadequado para consultas não delegáveis

As Funções delegáveis delegam o processamento de dados para as origem de dados, minimizando a sobrecarga do lado do cliente. Quando a delegação não é possível, pode restringir o limite da linha de dados para consultas não delegáveis, de modo a que o número de linhas obtidas de uma ligação baseada no servidor permaneça otimizada.

A utilização de funções não delegáveis e de limites de linha de dados para consultas não delegáveis inadequado adicionam uma sobrecarga extra à transferência de dados. Esta sobrecarga resulta na manipulação dos dados recebidos para a pilha JS do lado do cliente. Certifique-se de que utiliza funções delegáveis para a aplicação sempre que disponível, e utiliza o limite ideal de linha de dados para consultas não delegáveis.

Mais informações: Utilizar delegações, Descrição geral da delegação

Evento OnStart precisa de afinação

O evento OnStart é executado quando a aplicação está a ser carregada. Chamar grandes quantidades de dados usando as funções na propriedade OnStart da aplicação fará com que a aplicação carregue lentamente. Um ecrã que tem forte dependência de controlos e valores definidos noutro ecrã será afetado pela navegação lenta no ecrã.

As seguintes secções descrevem alguns dos problemas mais comuns nestas situações.

Elevado número de chamadas no evento OnStart fazendo com que a aplicação comece lentamente

Numa empresa, o volume de chamadas de dados para uma origem de dados central pode impulsionar estrangulamentos do servidor ou a contenção de recursos.

Use um mecanismo de cache para otimizar as chamadas de dados. Uma única aplicação pode ser utilizada por muitos utilizadores, resultando em várias chamadas de dados por utilizador que chegam aos pontos finais do servidor. Estas chamadas de dados podem ser um local onde o estrangulamento, ou limitação pode ocorrer.

Latência no evento OnStart por causa de scripts pesados

Scripts pesados no evento OnStart são um dos erros mais comuns ao conceber aplicações de tela. Só deve obter os dados necessários para que a aplicação inicie.

Otimize a fórmula num evento OnStart. Por exemplo, em vez disso, pode mover algumas funções para a propriedade OnVisible. Desta forma, pode deixar a aplicação iniciar rapidamente, e outros passos podem continuar enquanto a aplicação abre.

Mais informações: Otimizar a propriedade OnStart

Sugestão

Recomendamos a utilização da propriedade App.StartScreen porque simplifica o lançamento da aplicação e aumenta o desempenho da aplicação.

Pressão de memória no lado do cliente

É importante verificar o consumo de memória de uma aplicação de tela, pois a maioria das vezes a aplicação é executada em dispositivos móveis. As exceções à memória na pilha são a causa mais provável por trás de uma aplicação de tela que falha ou congela ("bloqueia") em certos dispositivos.

Uma pilha JavaScript (JS) pode atingir o limite devido a scripts pesados executados do lado do cliente para adicionar, juntar, filtrar, ordenar ou agrupar colunas. Na maioria dos casos, uma exceção de sem memória na pilha num cliente pode acionar a falha ou o bloqueio da aplicação.

Ao utilizar dados a partir de origens, como Dataverse ou SQL Server, pode utilizar um objeto Ver para garantir que a junção, filtro, agrupamento ou ordenação ocorre no lado do servidor em vez do lado do cliente. Esta abordagem reduz a sobrecarga de scripts dos clientes para tais ações.

Se operações pesadas de clientes como JUNTAR ou Agrupar Por aconteceram do lado do cliente com um conjunto de dados com 2.000 registos ou mais, os objetos na pilha aumentarão resultando em exceder os limites de memória.

As ferramentas de programação para a maioria dos browsers permitem-lhe criar um perfil da memória. Ajuda-o a visualizar o tamanho da pilha, documentos, nós e ouvintes. Perfile o desempenho da aplicação utilizando um browser, conforme descrito na Descrição geral das Ferramentas de Programação do Microsoft Edge (Chromium). Verifique os cenários que excedem o limiar de memória da pilha JS. Mais informações: Corrigir problemas de memória

Considerações de desempenho para o conector do SQL Server

Pode utilizar o conector do SQL Server para o Power Apps para se ligar ao SQL Server no local ou à Base de Dados SQL do Azure. Esta secção descreve problemas comuns relacionados com o desempenho e resoluções para a utilização deste conector para uma aplicação de tela.

Nota

Embora esta secção referencie o conector do SQL Server para problemas e resoluções de desempenho, a maioria das recomendações também se aplica para utilizar qualquer tipo de base de dados—como MySQL ou PostgreSQL—como a origem de dados.

Vejamos os problemas e resoluções comuns de desempenho para utilizar o conector do SQL Server para aplicações de tela.

Consulta N+1

Galerias que geram demasiados pedidos para servidores causam problemas de consulta N+1. O problema da consulta N+1 é um dos problemas mais frequentemente experimentados com a utilização do controlo da Galeria.

Para evitar o problema, utilize ver objetos no back-end do SQL ou altere os cenários de interface do utilizador.

Análise de tabela em vez de procura de índice

Uma aplicação pode abrandar se as funções utilizadas pela aplicação executarem consultas na base de dados que resultam em análises de tabela, em vez de procura de índice. Mais informações: Dicas, ANÁLISE de Tabela e PROCURA DE Índice

Para resolver estes problemas, utilize StartsWith, em vez de IN na fórmula. Com uma origem de dados SQL, o operador StartsWith resulta numa procura de índice, mas o operador IN resulta numa análise de tabela ou de índice.

Consultas lentas

Pode criar um perfil e sintonize consultas lentas e índices na base de dados SQL. Por exemplo, se uma fórmula obtiver dados com ordem descendente (DESC) numa determinada coluna, essa coluna de ordenação deve ter um índice com ordem descendente. A chave de índice cria ordem ascendente (ASC) por predefinição.

Também pode verificar o endereço URL dos pedidos de dados. Por exemplo, o seguinte fragmento de pedido de dados (chamada OData parcial) pede ao SQL que obtenha 500 registos correspondendo a coluna ao Valor e ordenado por ID em ordem descendente.

Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500

Isto ajuda a compreender os requisitos do índice para cobrir condições de pedido semelhantes. Neste exemplo, se a coluna ID tiver um índice com ordem descendente, a consulta será efetuada mais rapidamente.

Verifique o plano de execução de consultas lentas para ver se existe alguma análise de tabela ou de índice. Monitorize quaisquer custos excessivos da pesquisa de chaves no plano de execução.

Mais informações:

• Monitorizar e afinar o desempenho
• Monitorizar o desempenho utilizando o Arquivo de Consultas
• Descrição geral de Eventos Alargados

Contenção de recursos de base de dados

Certifique-se de que a—base de dados SQL—da origem de dados não tem qualquer contenção de recursos, tais como estrangulamentos do processador, contenção de E/S, pressão de memória ou contenção tempDB. Verifique também se há bloqueios, esperas, impasses e tempos limite de consulta.

Sugestão

Utilize sintonização automática para obter informações sobre potenciais problemas de desempenho de consulta, soluções recomendadas e para corrigir automaticamente os problemas identificados.

Cliente espesso ou pedidos excessivos

Uma aplicação que executa operações do Agrupar Por, Filtrar Por ou JUNTAR no processador de utilização do lado do cliente e recursos de memória dos dispositivos de cliente. Dependendo do tamanho dos dados, estas operações podem demorar mais tempo de script no lado do cliente, aumentando o tamanho da pilha JS no cliente. Este problema aumenta para uma origem de dados no local uma vez que cada chamada de dados de pesquisa viaja para a origem de dados através do gateway de dados.

Nestas situações, utilize o objeto Ver na base de dados SQL para as operações Agrupar Por, Filtrar Por ou JUNTAR. As vistas podem utilizar colunas seletivas e remover colunas desnecessárias com tipos de macrodados, tais como NVARCHAR(MAX), VARCHAR(MAX) e VARBINARY(MAX).

Sugestão

Esta abordagem também ajuda a resolver o problema da consulta N+1.

Tamanho dos dados transferido para o cliente

Por predefinição, uma aplicação de tela mostra dados usando as tabelas ou vistas dos objetos de base de dados disponíveis. A obtenção de todas as colunas de uma tabela pode resultar numa resposta lenta, especialmente quando se utilizam tipos de macrodados, tais como NVARCHAR(MAX).

A transferência de grandes quantidades de dados para os clientes leva tempo. Esta transferência também resulta em mais tempo de scripting quando há grandes quantidades de dados na pilha JS do lado do cliente, como descrito anteriormente neste artigo.

Para reduzir o tamanho dos dados que são transferidos para o cliente, utilize vistas com as colunas específicas necessárias para a aplicação e certifique-se de que a seleção explícita de colunas está ativada, como descrito anteriormente neste artigo.

Considerações específicas do SQL Server no local

O desempenho de uma aplicação de tela utilizando o conector do SQL Server com um gateway de dados no local pode ser afetado de várias maneiras. Esta secção enumera as questões e resoluções de desempenho comuns específicas da utilização de uma origem de base de dados no local.

Gateway de dados no local em mau estado de funcionamento

As organizações podem definir múltiplos nós para gateways de dados no local. Mesmo que só um dos nós seja inacessível, os pedidos de dados para o nó em mau estado de funcionamento não devolvem o resultado dentro de um período de tempo aceitável, ou podem causar mensagens de erro depois de esperar por algum tempo.

Certifique-se de que todos os nós do gateway de dados no local estão em bom estado de funcionamento e configurados com uma latência mínima de rede entre os nós e a instância SQL.

Localização do gateway de dados no local

Um gateway de dados requer chamadas de rede para origens de dados no local para interpretar os pedidos OData. Por exemplo, o portal de dados precisa de compreender o esquema da tabela de dados para traduzir os pedidos de OData em declarações de idioma de manipulação de dados SQL (DML). A sobrecarga extra é adicionada quando o gateway de dados é configurado numa localização separada com alta latência de rede entre o gateway de dados e a instância SQL.

Num ambiente empresarial, recomenda-se um cluster de gateway de dados escalável quando são esperados pedidos de dados pesados. Verifique quantas ligações são estabelecidas entre os nós do gateway de dados e a instância SQL.

Ao verificar as ligações simultâneas num gateway de dados no local ou numa instância SQL, a sua organização pode identificar o ponto em que o gateway de dados precisa de escalar horizontalmente e com quantos nós.

Escalabilidade de gateway de dados

Se espera aceder a um grande volume de dados a partir do gateway de dados no local, apenas um nó no gateway de dados no local pode tornar-se um estrangulamento no processamento de um volume tão grande de pedidos.

Um único nó do gateway de dados no local pode ser suficiente para lidar com 200 ou menos ligações simultâneas. No entanto, se todas estas ligações simultâneas estiverem a executar consultas ativamente, outros pedidos acabam por esperar por uma ligação disponível.

Para obter informações sobre como certificar-se de que o seu gateway de dados no local escala de acordo com o volume de dados e pedidos, vá a Monitorizar e otimizar o desempenho do gateway de dados no local.

Considerações específicas da Base de Dados SQL do Azure

As aplicações de tela podem ligar-se à Base de Dados SQL do Azure utilizando o conector do SQL Server. Uma causa comum de problemas de desempenho ao utilizar a Base de Dados SQL do Azure é selecionar o escalão errado para os requisitos do seu negócio.

A Base de Dados SQL do Azure está disponível em diferentes escalões de serviço, com capacidades variadas para corresponder a diferentes requisitos de negócio. Para mais informações sobre escalões, vá a documentação da Base de Dados SQL do Azure.

Com pedidos de dados pesados, os recursos no escalão selecionado podem ser limitados assim que o valor do limiar for atingido. Tal limitação compromete o desempenho do próximo conjunto de consultas.

Consulte o escalão de serviço da Base de Dados SQL do Azure. Um escalão mais baixo terá algumas limitações e constrangimentos. Do ponto de vista do desempenho, CPU, débito E/S e latência são importantes. Por isso, recomendamos que verifique periodicamente o desempenho da base de dados SQL e verifique se a utilização do recurso excede o limiar. Por exemplo, o SQL Server local, normalmente, define o limiar de utilização da CPU para cerca de 75por cento.

Considerações de desempenho para o conector do SharePoint

Pode utilizar o conector do SharePoint para criar aplicações de tela utilizando dados de Listas Microsoft. Também pode criar aplicações de tela diretamente a partir da vista de lista. Vejamos os problemas e resoluções comuns de desempenho ao utilizar uma origem de dados do SharePoint com aplicações de tela.

Demasiadas colunas de pesquisa dinâmica

O SharePoint suporta vários tipos de dados, incluindo pesquisas dinâmicas, como Pessoa, Grupo e Calculada. Se uma lista definir demasiadas colunas dinâmicas, leva mais tempo a manipular estas colunas dinâmicas no SharePoint antes de obter os dados para o cliente que executa a aplicação de tela.

Não utilize em excesso as colunas de pesquisa dinâmicas no SharePoint. Este uso excessivo pode resultar em sobrecargas evitáveis e adicionais no lado do SharePoint para a manipulação de dados. Alternativamente, pode usar colunas estáticas para manter pseudónimos de e-mail, ou nomes das pessoas, por exemplo.

Coluna de imagem e anexo

O tamanho de uma imagem e o ficheiro anexado podem contribuir para uma resposta lenta enquanto são obtidos do cliente.

Reveja a sua lista e certifique-se de que apenas as colunas necessárias foram definidas. O número de colunas na lista afeta o desempenho dos pedidos de dados. Este efeito deve-se aos registos correspondidos, ou os registos até aos limites definidos da linha de dados são obtidos e transmitidos de volta ao cliente com todas as colunas definidas na lista, mesmo se a aplicação não utilizar todas elas.

Para consultar apenas as colunas utilizadas pela aplicação, ative a funcionalidade de seleção de colunas explícita, como descrito anteriormente neste artigo.

Listas grandes

Se tiver uma lista grande com centenas de milhares de registos, considere criar partições da lista ou dividi-la em várias listas com base em parâmetros como as categorias ou data e hora.

Por exemplo, os seus dados podem ser armazenados em diferentes listas numa base anual ou mensal. Nesse caso, pode projetar a aplicação para permitir que um utilizador selecione uma janela de tempo e recuperar os dados dentro desse intervalo.

Num ambiente controlado, a referência de desempenho provou que o desempenho de pedidos OData relativamente a Listas Microsoft ou SharePoint está altamente relacionado com o número de colunas na lista e com o número de linhas que estão a ser obtidas (limitada pelo limite da linha de dados para consultas não delegáveis). Ter um menor número de colunas e uma definição de limite de linha de dados mais baixa pode fazer com que uma aplicação de tela tenha melhor desempenho.

No entanto, no mundo real as aplicações são concebidas para satisfazer certos requisitos do negócio. Pode não ser rápido ou simples reduzir o limite da linha de dados, ou o número de colunas numa lista. No entanto, recomendamos que monitorize os pedidos OData do lado do cliente, e sintonizar o limite da linha de dados para consultas não delegáveis e o número de colunas na lista.

Considerações de desempenho para usar o Dataverse como origem de dados

Quando utiliza Microsoft Dataverse como origem de dados, os pedidos de dados vão diretamente para o ambiente, sem passar pela Azure API Management. Mais informações: Fluxo de chamada de dados ao ligar-se a Microsoft Dataverse

Sugestão

Quando as tabelas personalizadas são utilizadas em Dataverse, poderá ser necessária uma configuração adicional de segurança para que os utilizadores possam ver os registos com aplicações de tela. Mais informações: Conceitos de segurança no Dataverse, Configurar a segurança de utilizador para recursos num ambiente e Direitos de acesso e privilégios

Uma aplicação de tela ligada ao Dataverse pode funcionar lentamente se executar scripts pesados do cliente, como Filtrar Por ou JUNTAR do lado do cliente em vez do lado do servidor.

Utilize Vistas do Dataverse sempre que possível. Uma vista com os critérios de adesão ou filtro necessários ajuda a reduzir a sobrecarga de utilização de uma tabela inteira. Por exemplo, se precisar de juntar tabelas e filtrar os seus dados, pode definir uma vista juntando-as e definir apenas as colunas que necessita. Em seguida, pode utilizar esta vista na sua aplicação, o que cria esta sobrecarga no lado do servidor para a operação juntar/filtrar em vez do lado do cliente. Este método não só reduz as operações adicionais, mas também a transmissão de dados. Para obter informações sobre a edição de critérios de filtros e de ordenação, aceda a Editar critérios de filtros.

Considerações de desempenho para o conector do Excel

O conector do Excel fornece conectividade de uma aplicação de tela para os dados numa tabela dentro num ficheiro Excel. Este conector tem limitações em comparação com outras origens de dados—por exemplo, funções delegáveis limitadas—que permitem à aplicação de tela carregar dados da tabela apenas até 2.000 registos. Para carregar mais de 2.000 registos, particione os seus dados em tabelas de dados diferentes como outras origens de dados.

Vejamos os problemas comuns de desempenho com a utilização do Excel como a origem de dados para aplicações de tela, e como resolvê-los.

Demasiadas tabelas de dados e grande tamanho de dados

Uma aplicação pode ter um desempenho lento quando utiliza um ficheiro Excel que tem demasiadas tabelas de dados, ou tabelas de dados que contêm um imenso tamanho de dados em várias colunas. Um ficheiro Excel não é uma base de dados relacional, ou uma origem de dados que fornece funções delegáveis. O Power Apps tem de carregar dados a partir das tabelas de dados definidas primeiro e, em seguida, utiliza funções como Filter, Sort, JOIN, Group By e Search.

Ter demasiadas tabelas de dados, com um muitas linhas e colunas, afetam o desempenho da aplicação e a sobrecarga do lado do cliente, porque cada tabela de dados precisa de ser manipulada dentro da pilha JS. Este efeito também leva a aplicação a consumir mais memória do lado do cliente.

Para garantir que a sua aplicação não é afetada por este problema, defina apenas as colunas de que necessita na tabela de dados num ficheiro Excel.

Transações pesadas

O Excel não é um sistema de base de dados relacional. Quaisquer alterações a partir de uma aplicação são geridas pelo Excel da mesma forma como se um utilizador mudasse dados num ficheiro Excel. Se a aplicação tiver um elevado número de operações de leitura, mas menos operações CRUD, poderá ter um bom desempenho. No entanto, se a aplicação fizer transações pesadas, poderá afetar negativamente o desempenho da aplicação.

Não há um valor limiar específico para o número de transações, porque também depende dos dados que estão a ser manipulados. Vários outros aspetos também afetam o desempenho da aplicação, como a sobrecarga da rede ou o dispositivo do utilizador.

Se tiver dados só de leitura, pode importar esses dados para a aplicação localmente, em vez de os carregar a partir da origem de dados. Para aplicações empresariais, utilize origens de dados como o Dataverse, SQL Server ou o SharePoint.

Tamanho do ficheiro

Pode escolher entre uma ampla gama de opções de armazenamento na nuvem com capacidade de armazenamento variada—ou configurável—para o ficheiro Excel. No entanto, ter um único ficheiro Excel grande com todas as tabelas definidas nesse ficheiro adiciona uma sobrecarga extra para a aplicação enquanto transfere o ficheiro e lê os dados para carregar no lado do cliente.

Em vez de utilizar um ficheiro grande, divida os dados em vários ficheiros Excel com tabelas de dados mínimas. Em seguida, ligue-se a cada ficheiro apenas quando precisar. Desta forma, o carregamento dos dados da tabela de dados acontece em fragmentos, reduzindo a sobrecarga de ter muitas tabelas, ou grandes conjunto de dados.

Localização do ficheiro

A localização geográfica da origem de dados, e a respetiva distância das localizações do cliente podem resultar num estrangulamento de desempenho para a aplicação e induzir a latência da rede. Este efeito pode ser amplificado quando um cliente móvel tem largura de banda limitada para conectividade.

É melhor manter o ficheiro perto dos utilizadores (ou, a maioria dos utilizadores, se tiver uma audiência global) para que o ficheiro possa ser transferido rapidamente.

Passos seguintes

Dicas e melhores práticas para melhorar o desempenho das aplicações de tela

Consulte também

Compreender as fases de execução e o fluxo de chamada de dados das aplicações de tela
Origens comuns de desempenho fraco para uma aplicação de tela
Problemas comuns e resoluções para o Power Apps
Resolução de problemas de arranque para Power Apps