Problemas comuns de desempenho e resoluções para aplicativos de tela

Você pode criar aplicativos de tela usando um conjunto diversificado de fontes de dados. Escolha a fonte de dados certa e um conector com base nas necessidades de negócios e nos cenários para os quais você está criando o aplicativo. Para aplicativos empresariais, o Microsoft Dataverse é a fonte de dados recomendada porque ele fornece vários benefícios de desempenho. Para aplicativos com poucas transações, você pode usar qualquer outra fonte de dados disponível no ambiente.

Para considerações de desempenho de um aplicativo, pense no número de usuários que usarão o aplicativo quando ele for publicado; o volume de transações de criação, recuperação, atualização e exclusão (CRUD); o tipo de interações de dados; acesso geográfico; e os tipos de dispositivos que os usuários possuem.

Neste artigo, você aprenderá sobre alguns dos problemas de desempenho mais comuns que podem fazer com que os aplicativos de tela sejam executados lentamente e como resolvê-los. Essas informações ajudarão você a melhorar o desempenho do aplicativo, considerando o plano de negócios e o crescimento.

Começaremos com alguns dos problemas comuns de desempenho, que ocorrem independentemente do conector usado. Nas próximas seções, você aprenderá sobre problemas de desempenho e resoluções específicas para vários conectores.

Antes de começar, verifique se compreendeu as fases de execução de aplicativos de tela e o fluxo de chamada de dados. Além disso, leia Fontes comuns de desempenho lento para um aplicativo de tela para saber mais sobre armadilhas comuns que você pode evitar ao criar ou atualizar aplicativos de tela.

Grandes conjuntos de dados carregados lentamente em plataformas diferentes

O desempenho de um aplicativo pode variar ao carregar grandes conjuntos de dados em diferentes plataformas, como iOS ou Android. Essa variação ocorre devido a diferentes limitações de solicitação de rede em cada plataforma. Por exemplo, o número de solicitações de rede simultâneas permitidas pode variar de acordo com a plataforma. Essa diferença pode ter um grande impacto no tempo de carregamento de dados para grandes conjuntos de dados.

Recomendamos que você carregue apenas os dados necessários para exibir imediatamente na tela. Para outros dados, pagine-os e armazene-os em cache. Mais informações: Dicas e práticas recomendadas para melhorar o desempenho do aplicativo de tela

Muitas colunas recuperadas

É recomendável selecionar apenas as colunas necessárias para o aplicativo. Ao adicionar mais (ou todas) as colunas da fonte de dados, você baixa todos os dados das colunas. Essa ação resulta em um grande número de chamadas de sobrecarga de rede e, portanto, em alto uso de memória no dispositivo cliente. Este problema pode afetar usuários com dispositivos móveis, ainda mais se a largura de banda da rede for limitada ou se um dispositivo tiver memória limitada ou um processador legado.

Por exemplo, se você usar o Dataverse como a fonte de dados do aplicativo, verifique se ativou o recurso seleção de coluna explícita. Este recurso permite que o Power Apps restrinja a recuperação de dados apenas para as colunas usadas no aplicativo.

Para ativar o recurso de seleção de coluna explícita no aplicativo de tela, acesse Configurações>Recursos futuros>Versão preliminar e, em seguida, ligue a opção Seleção de coluna explícita.

Navegadores sem suporte ou legados

Os usuários que usam navegadores sem suporte ou legados podem ter problemas de desempenho. Garanta que os usuários usem apenas navegadores com suporte para executar aplicativos de tela.

Desempenho lento devido à distância geográfica

A localização geográfica do ambiente e a distância da fonte de dados dos usuários podem afetar o desempenho.

Recomendamos que o ambiente esteja localizado próximo aos usuários. Embora o Power Apps use a Rede de Distribuição de Conteúdo do Azure para conteúdo, as chamadas de dados ainda obtêm os dados da fonte de dados. Uma fonte de dados localizada em outra geolocalização pode afetar negativamente o desempenho do aplicativo.

A distância geográfica excessiva afeta o desempenho de diferentes formas, como latência, taxa de transferência reduzida, largura de banda mais baixa ou perda de pacotes.

Lista de permitidos não configurada

Certifique-se de que as URLs de serviço obrigatórias não foram bloqueadas ou que foram adicionadas à lista de permissões do firewall. Para obter uma lista completa de todas as URLs de serviço que precisam ser permitidas para o Power Apps, acesse Serviços obrigatórios.

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

As funções delegáveis delegam o processamento de dados para a fonte de dados, minimizando a sobrecarga no cliente. Quando a delegação não é possível, você pode restringir o limite de linha de dados para consultas não delegáveis para que o número de linhas retornadas de uma conexão baseada em servidor permaneça ideal.

O uso de funções não delegáveis e limites de linha de dados inadequados para consultas não delegáveis adicionam sobrecarga extra à transferência de dados. Essa sobrecarga resulta na manipulação dos dados recebidos para o heap do JS no cliente. Utilize funções delegáveis para o aplicativo sempre que disponíveis e use o limite de linha de dados ideal para consultas não delegáveis.

Mais informações: Usar delegação, Visão geral de delegação

O evento OnStart precisa de ajuste

O evento OnStart é executado quando o aplicativo está sendo carregado. Chamar grandes volumes de dados usando as funções na propriedade OnStart do aplicativo fará com que o aplicativo carregue lentamente. Uma tela muito dependente de controles e valores definidos em outra tela será afetada pela navegação lenta de tela.

As seções a seguir descrevem alguns dos problemas mais comuns encontrados nessas situações.

Grande número de chamadas no evento OnStart fazendo com que o aplicativo inicie lentamente

Em uma empresa, o volume de chamadas de dados para uma fonte de dados central pode causar gargalos no servidor ou contenção de recursos.

Use um mecanismo de cache para otimizar chamadas de dados. Um único aplicativo deve ser usado por muitos usuários, resultando em várias chamadas de dados por usuário que chegam nos pontos de extremidade do servidor. Essas chamadas de dados podem ser um ponto em que o gargalo ou a limitação pode ocorrer.

Latência no evento OnStart devido a scripts pesados

Scripts pesados no evento OnStart são um dos erros mais comuns ao criar aplicativos de tela. Você deve obter apenas os dados necessários para o aplicativo iniciar.

Otimize a fórmula em um evento OnStart. Por exemplo, é possível algumas funções para a propriedade OnVisible. Dessa forma, você pode deixar o aplicativo iniciar rapidamente e outras etapas podem continuar enquanto o aplicativo é aberto.

Mais informações: Otimize a propriedade OnStart

Dica

É recomendável usar a propriedade App.StartScreen, pois ela simplifica o lançamento do aplicativo e aumenta o desempenho dele.

Pressão de memória no cliente

É importante verificar o consumo de memória de um aplicativo de tela porque, na maioria das vezes, o aplicativo é executado em dispositivos móveis. As exceções de memória no heap são a causa mais provável por trás de um aplicativo de tela que falha ou congela ("trava") em determinados dispositivos.

Um heap do JavaScript (JS) pode atingir o limite por causa de scripts pesados executados no cliente para adicionar, unir, filtrar, classificar ou agrupar colunas. Na maioria dos casos, uma exceção de memória insuficiente no heap de um cliente pode fazer o aplicativo falhar ou travar.

Ao usar dados de fontes como Dataverse ou SQL Server, você pode usar um objeto Exibir para garantir que o ingresso, a filtragem, o agrupamento ou a classificação ocorra no servidor e não no cliente. Essa abordagem reduz a sobrecarga de script do cliente para tais ações.

Se as operações que exigem muito do cliente, como INGRESSAR ou Agrupar por, ocorrerem no cliente com um conjunto de dados com 2.000 registros ou mais, os objetos no heap aumentarão, excedendo os limites de memória.

As ferramentas para desenvolvedores para a maioria dos navegadores permitem que você crie perfis de memória. Isso ajuda a visualizar o tamanho do heap, documentos, nós e ouvintes. Crie um perfil de desempenho do aplicativo usando um navegador, conforme descrito em Visão geral de Ferramentas de Desenvolvedor do Microsoft Edge (Chromium). Verifique os cenários que excedem o limite de memória do heap do JS. Mais informações: Resolva problemas de memória

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

Você pode usar o Conector do SQL Server para o Power Apps para se conectar ao SQL Server local ou ao Banco de Dados SQL do Azure. Esta seção descreve problemas comuns relativos ao desempenho e resoluções para usar este conector para um aplicativo de tela.

Observação

Embora esta seção faça referência ao conector do SQL Server para problemas de desempenho e resoluções, a maioria das recomendações também se aplica ao uso de qualquer tipo de banco de dados como a fonte de dados; por exemplo, MySQL ou PostgreSQL.

Vamos conferir os problemas comuns de desempenho e as resoluções para uso do conector do SQL Server para aplicativos de tela.

Consulta N+1

As galerias que geram muitas solicitações aos servidores causam problemas de consulta N+1. O problema de consulta N+1 é um dos problemas mais comuns ao usar o controle da galeria.

Para evitar o problema, use exibir objetos no back-end SQL ou altere os cenários de interface do usuário.

Verificação de tabela em vez de busca de índice

Um aplicativo poderá ficar lento se as funções usadas pelo aplicativo executarem consultas no banco de dados que resulte em verificações de tabela em vez de busca de índice. Mais informações: Dicas, VERIFICAÇÃO de tabela e BUSCA de índice

Para resolver esses problemas, use StartsWith em vez de IN na fórmula. Com uma fonte de dados do SQL, o operador StartsWith resulta em uma busca de índice; mas o operador IN resulta em uma verificação de índice ou tabela.

Consultas lentas

Você pode criar perfis e ajustar as consultas e índices lentos no banco de dados SQL. Por exemplo, se uma fórmula obtiver dados com ordem decrescente (DESC) em determinada coluna, essa coluna de classificação deverá ter um índice com ordem decrescente. A chave de índice cria uma ordem crescente (ASC) por padrão.

Você também pode verificar o endereço URL das solicitações de dados. Por exemplo, o trecho a seguir de solicitação de dados (chamada OData parcial) solicita ao SQL que retorne 500 registros correspondentes à coluna para Valor e ordene por ID em ordem decrescente.

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

Isso ajuda a entender os requisitos de índice para abranger condições de solicitação semelhantes. Neste exemplo, se a coluna ID tiver um índice em ordem decrescente, a consulta será executada com mais rapidez.

Verifique o plano de execução de consultas lentas para ver se existe uma verificação de tabela ou índice. Monitore custos excessivos de pesquisa de chave no plano de execução.

Para obter mais informações:

• Monitore e ajuste o desempenho
• Monitorar o desempenho usando o Repositório de Consultas
• Visão geral de eventos estendidos

Contenção de recursos de banco de dados

Verifique se a fonte de dados, o banco de dados SQL, não tem contenções de recursos, como gargalos do processador, contenção de E/S, pressão de memória ou contenção tempDB. Verifique também bloqueios, esperas, deadlocks e tempos limite de consulta.

Dica

Use o ajuste automático para obter insights sobre possíveis problemas de desempenho de consulta, soluções recomendadas e para corrigir automaticamente os problemas identificados.

Cliente pesado ou solicitações excessivas

Um aplicativo que executa operações Agrupar Por, Filtrar Por ou INGRESSAR no cliente usa o processador e os recursos de memória dos dispositivos do cliente. Dependendo do tamanho dos dados, essas operações podem levar mais tempo de script no cliente, aumentando o tamanho do heap do JS no cliente. Este problema aumenta para uma fonte de dados local, pois cada chamada de dados de pesquisa viaja para a fonte de dados por meio do gateway de dados.

Em tais situações, use o objeto Exibir no banco de dados SQL para as operações Agrupar Por, Filtrar Por ou INGRESSAR. As exibições podem usar colunas seletivas e remover colunas desnecessárias com tipos de Big Data, como NVARCHAR(MAX), VARCHAR(MAX) e VARBINARY(MAX).

Dica

Essa abordagem também ajuda a resolver o problema de consulta N+1.

Tamanho dos dados transferidos para o cliente

Por padrão, um aplicativo de tela mostra dados usando as tabelas ou exibições dos objetos de banco de dados disponíveis. A recuperação de todas as colunas de uma tabela pode resultar em uma resposta lenta, especialmente ao usar tipos de Big Data como NVARCHAR(MAX).

A transferência de grandes volumes de dados para clientes leva tempo. Essa transferência também resulta em mais tempo de script quando há grandes volumes de dados no heap do JS no cliente, conforme descrito anteriormente neste artigo.

Para reduzir o tamanho dos dados transferidos para o cliente, use exibições com as colunas específicas necessárias para o aplicativo e garanta que a seleção de coluna explícita esteja habilitada, conforme descrito anteriormente neste artigo.

Considerações específicas para o SQL Server local

O desempenho de um aplicativo de tela que usa o conector do SQL Server com um gateway de dados local pode ser afetado de várias maneiras. Esta seção lista os problemas comuns de desempenho e as resoluções específicas para o uso de uma fonte de banco de dados local.

Gateway de dados local não íntegro

As organizações podem definir vários nós para gateways de dados locais. Se até mesmo um dos nós estiver inacessível, as solicitações de dados para o nó não íntegro não retornarão o resultado em um período aceitável, ou elas poderão causar mensagens de erro "inacessíveis" depois de esperar um pouco.

Certifique-se de que todos os nós de gateway de dados local estejam íntegros e configurados com uma latência de rede mínima entre os nós e a instância SQL.

Localização do gateway de dados local

Um gateway de dados requer chamadas de rede para fontes de dados locais para interpretar as solicitações OData. Por exemplo, o gateway de dados precisa entender o esquema da tabela de dados para traduzir solicitações OData em instruções DML (linguagem de manipulação de dados) SQL. A sobrecarga extra é adicionada quando o gateway de dados é configurado em um local separado com alta latência de rede entre o gateway de dados e a instância SQL.

Em um ambiente corporativo, ter um cluster de gateway de dados escalonável é recomendado quando são esperadas muitas solicitações de dados. Verifique quantas conexões são estabelecidas entre os nós de gateway de dados e a instância SQL.

Ao verificar as conexões simultâneas em um gateway de dados local ou em uma instância SQL, sua organização pode identificar o ponto em que o gateway de dados precisa ser expandido e com quantos nós.

Escalabilidade de gateway de dados

Se você espera acessar um grande volume de dados do gateway de dados local, apenas um único nó do gateway de dados local pode se tornar um gargalo ao tratar esse grande volume de solicitações.

Um único nó do gateway de dados local deve ser suficiente para tratar 200 ou menos conexões simultâneas. Entretanto, se todas essas conexões simultâneas estiverem executando consultas ativamente, outras solicitações acabarão esperando por uma conexão disponível.

Para obter informações sobre como garantir que o gateway de dados local seja dimensionado de acordo com o volume de dados e solicitações, vá para Monitorar e otimizar o desempenho do gateway de dados local.

Considerações específicas para o Banco de Dados SQL do Azure

Os aplicativos de tela podem se conectar ao Banco de Dados SQL do Azure usando o conector do SQL Server. Uma causa comum de problemas de desempenho ao usar o Banco de Dados SQL do Azure é selecionar a camada errada para seus requisitos de negócios.

O Banco de Dados SQL do Azure está disponível em diferentes camadas de serviço, com recursos variados para atender a diferentes requisitos de negócios. Para obter mais informações sobre níveis, vá para a documentação do Banco de Dados SQL do Azure.

Com muitas solicitações de dados, os recursos no nível que você seleciona podem ser limitados assim que o valor limite é atingido. Essa limitação compromete o desempenho do próximo conjunto de consultas.

Verifique a camada de serviço do Banco de Dados SQL do Azure. Um nível inferior terá algumas limitações e restrições. De uma perspectiva de desempenho, a CPU, a taxa de transferência de E/S e a latência são importantes. Então, é recomendável verificar o desempenho do banco de dados SQL periodicamente e se o uso de recursos excede o limite. Por exemplo, normalmente o SQL Server local define o limite de uso da CPU em cerca de 75%.

Considerações de desempenho para o conector do SharePoint

Você pode usar o conector do SharePoint para criar aplicativos usando dados de Listas da Microsoft. Você também pode criar aplicativos de tela diretamente da exibição de lista. Vamos conferir os problemas comuns de desempenho e resoluções para usar uma fonte de dados do SharePoint com aplicativos de tela.

Muitas colunas de pesquisa dinâmica

O SharePoint é compatível com vários tipos de dados, incluindo pesquisas dinâmicas, como Pessoa, Grupo e Calculado. Se uma lista define muitas colunas dinâmicas, leva mais tempo para manipular essas colunas dinâmicas dentro do SharePoint antes de retornar dados ao cliente que executa o aplicativo de tela.

Não faça uso excessivo das colunas de pesquisa dinâmica no SharePoint. Este uso excessivo pode resultar em sobrecarga extra evitável no SharePoint para manipulação de dados. Em vez disso, você pode usar colunas estáticas para manter aliases de email ou nomes de pessoas, por exemplo.

Coluna de imagem e anexo

O tamanho de uma imagem e um arquivo anexado podem contribuir para uma resposta lenta ao recuperar para o cliente.

Analise a lista e garanta que apenas as colunas necessárias foram definidas. O número de colunas na lista afeta o desempenho das solicitações de dados. Isso ocorre porque os registros correspondentes, ou os registros até os limites de linha de dados definidos, são recuperados e retransmitidos para o cliente com todas as colunas definidas na lista – mesmo se o aplicativo não usar todas.

Para consultar apenas as colunas usadas pelo aplicativo, habilite o recurso de seleção de coluna explícita, conforme descrito anteriormente neste artigo .

Listas grandes

Se você tiver uma lista grande com centenas de milhares de registros, considere o particionamento da lista ou a divisão dela em várias listas com base em parâmetros como categorias ou data e hora.

Por exemplo, seus dados podem ser armazenados em listas diferentes anualmente ou mensalmente. Nesse caso, você pode criar o aplicativo para permitir que um usuário selecione uma janela de tempo e recupere os dados nesse intervalo.

Dentro de um ambiente controlado, o parâmetro de comparação de desempenho provou que o desempenho de solicitações OData em relação a Listas da Microsoft ou SharePoint está altamente relacionado ao número de colunas na lista e ao número de linhas sendo recuperadas (limitado pelo limite de linhas de dados para consultas não delegáveis). Ter menos colunas e uma configuração inferior de limite de linha de dados pode levar um aplicativo de tela ter um desempenho melhor.

Porém, na realidade, os aplicativos são criados para atender a certos requisitos de negócios. Pode não ser rápido nem simples reduzir o limite de linha de dados ou o número de colunas em uma lista. No entanto, é recomendável monitorar as solicitações OData no cliente e ajustar o limite de 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 a fonte de dados

Quando você usa o Microsoft Dataverse como fonte de dados, as solicitações de dados vão diretamente para a instância do ambiente sem passar pelo Gerenciamento de API do Azure. Mais informações: Fluxo de chamada de dados ao conectar-se ao Microsoft Dataverse

Dica

Quando tabelas personalizadas forem usadas no Dataverse, a configuração de segurança adicional poderá ser necessária para que os usuários possam exibir os registros com aplicativos de tela. Mais informações: Conceitos de segurança no Dataverse, Configurar a segurança do usuário para recursos em um ambiente e Direitos de acesso e privilégios

Um aplicativo de tela conectado ao Dataverse poderá ter um desempenho lento se executar scripts pesados de clientes, como Filtrar por ou INGRESSAR no cliente e não no servidor.

Use as Visualizações do Dataverse quando possível. Uma exibição com os critérios de junção ou filtro necessários ajuda a reduzir a sobrecarga de usar uma tabela inteira. Por exemplo, se precisar unir tabelas e filtrar seus dados, você poderá definir uma exibição ao juntá-las e definir somente as colunas necessárias. Você pode usar esta exibição no aplicativo, que cria essa sobrecarga no servidor para a operação ingressar/filtrar, não no cliente. Este método reduz não apenas as operações extras, mas também a transmissão de dados. Para obter informações sobre como editar filtros e critérios de classificação, vá para Editar os critérios do filtro.

Considerações de desempenho para o conector do Excel

O conector do Excel fornece conectividade de um aplicativo de tela para os dados em uma tabela em um arquivo Excel. Este conector tem limitações em comparação com outras fontes de dados; por exemplo, funções delegáveis limitadas, que restringem o aplicativo de tela a carregar dados da tabela apenas até 2.000 registros. Para carregar mais de 2.000 registros, particione os dados em diferentes tabelas de dados como outras fontes de dados.

Vamos conferir os problemas comuns de desempenho ao usar o Excel como a fonte de dados para aplicativos de tela e como resolvê-los.

Muitas tabelas de dados e grande tamanho de dados

Um aplicativo pode ser executado lentamente quando ele usa um arquivo Excel que tem muitas tabelas de dados ou tabelas com um grande volume de dados em várias colunas. Um arquivo Excel não é um banco de dados relacional ou uma fonte de dados que fornece funções delegáveis. O Power Apps precisa primeiro carregar os dados das tabelas de dados definidas e, em seguida, usa funções como Filter, Sort, JOIN, Group By e Search.

Ter muitas tabelas de dados com muitas linhas e colunas afeta o desempenho do aplicativo e a sobrecarga do cliente porque cada tabela de dados precisa ser manipulada no heap do JS. Esse efeito também faz com que o aplicativo consuma mais memória do cliente.

Para garantir que seu aplicativo não seja afetado por esse problema, defina apenas as colunas necessárias na tabela de dados em um arquivo Excel.

Transações intensas

O Excel não é um sistema de banco de dados relacional. Todas as alterações de um aplicativo são gerenciadas pelo Excel da mesma forma que se um usuário estivesse alterando dados em um arquivo do Excel. Se o aplicativo tiver muitas leituras, mas menos operações CRUD, ele poderá funcionar bem. No entanto, se o aplicativo fizer transações intensas, isso poderá afetar negativamente o desempenho do aplicativo.

Não há um valor limite específico para o número de transações, pois ele também depende dos dados que estão sendo manipulados. Vários outros aspectos também afetam o desempenho do aplicativo, como a sobrecarga da rede ou o dispositivo do usuário.

Se você tiver dados somente leitura, poderá importar esses dados para o aplicativo localmente em vez de carregá-los na fonte de dados. Para aplicativos empresariais, use fontes de dados como Dataverse, SQL Server ou SharePoint.

Tamanho do arquivo

Você pode escolher entre uma grande variedade de opções de armazenamento em nuvem com capacidade de armazenamento variável, ou configurável, para o arquivo Excel. No entanto, ter um único arquivo grande do Excel com todas as tabelas definidas nesse arquivo adiciona uma sobrecarga extra ao aplicativo enquanto ele baixa o arquivo e lê dados para carregar no cliente.

Em vez de usar um arquivo grande, divida os dados em vários arquivos do Excel com o mínimo de tabelas de dados. Em seguida, conecte-se a cada arquivo apenas quando for necessário. Dessa forma, o carregamento dos dados da tabela de dados ocorre em fragmentos, reduzindo a sobrecarga de ter muitas tabelas ou um conjunto de dados grande.

Local do arquivo

A geolocalização da fonte de dados e sua distância dos locais de clientes podem resultar em um gargalo de desempenho para o aplicativo 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 arquivo perto dos usuários (ou da maioria dos usuários se você tiver um público global) para que o arquivo possa ser baixado rapidamente.

Próximas etapas

Dicas e práticas recomendadas para melhorar o desempenho de aplicativos de tela

Confira também

Entender as fases de execução de aplicativos de tela e o fluxo de chamada de dados
Fontes comuns de desempenho lento para um aplicativo de tela
Problemas comuns e soluções do Power Apps
Solucionando problemas de inicialização do Power Apps