Outras considerações sobre o desempenho

Além dos quatro princípios-chave de desempenho, existem diversos outros motivos possíveis para o mau desempenho, normalmente por causa de fatores externos.

Levar em consideração as diferenças em navegadores cliente, dispositivos e locais

Os aplicativos de tela podem ser usados em diferentes dispositivos, navegadores e locais com diferentes condições de rede. À medida que o cliente do Power Apps é executado, não se esqueça de usar navegadores modernos, atualizados e compatíveis. 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 varia de acordo com a plataforma. Essas diferenças podem ter um grande impacto sobre o tempo de carregamento de dados para grandes conjuntos de dados.

Levar em consideração as diferenças na localização geográfica do gateway de dados local e do ambiente

Os usuários podem acessar aplicativos de tela globalmente. Contudo, recomendamos que você localize a fonte de dados perto da maioria de seus usuários. Por exemplo, quando o aplicativo acessa o gateway de dados local, é melhor colocar o gateway próximo dos usuários que acessam o aplicativo com mais frequência.

Problemas no lado do servidor em geral

O baixo desempenho pode ser causado por problemas no servidor de origem dos dados. Isso pode acontecer por motivos variados. Você pode usar a ferramenta de monitoramento para avaliar o problema específico medindo os tempos de chamada dos dados.

Problemas de gargalos possíveis na fonte de dados

Existem muitas causas possíveis para gargalos na fonte de dados. Normalmente, algumas tabelas na fonte de dados estão no centro da atividade de muitas consultas. As consultas poderão ficar lentas se:

• A fonte de dados não for encontrada ou tiver índices incorretos.
• A consulta estiver unindo quantidades de dados extraordinariamente grandes no servidor.
• A consulta exigir uma tabela SCAN; por exemplo, operador In, em vez de usar um índice como StartsWith.
• A máquina de back-end que hospeda a fonte de dados está com poucos recursos.
• A instância SQL de back-end tem bloqueios, deadlocks ou contenção de recursos.
• O gateway de dados local não é íntegro.
• O gateway de dados local deve ser expandido.

Se houver esses problemas, ajuste a fonte de dados de back-end para evitar lentidão no desempenho do aplicativo.

Fontes de dados específicas

Banco de Dados SQL do Azure

É importante selecionar o nível certo para os requisitos de negócios. Para obter mais informações, consulte Documentação do banco de dados SQL do Azure. Um nível inferior tem 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%.

SharePoint

O conector do SharePoint pode ser usado para criar aplicativos que usam dados de listas do SharePoint. Aqui estão alguns problemas comuns de desempenho e soluções para o SharePoint:

Evitar muitas colunas de pesquisa dinâmica: o SharePoint dá suporte a tipos de dados variados, inclusive 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. Para evitar isso, não use excessivamente as colunas de pesquisa dinâmica no SharePoint. Por exemplo, use colunas estáticas para manter aliases de email ou nomes de pessoas.

Usar com cuidado a coluna de imagem e o anexo: o tamanho de uma imagem e um arquivo anexado podem favorecer uma resposta lenta durante a recuperação 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.

Levar em consideração a divisão de listas grandes: se você tiver uma lista grande com centenas de milhares de registros, leve em consideração o particionamento ou a divisão da lista em várias listas com base em parâmetros como as categorias ou a data e a 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.

Dataverse

Quando você usa o Microsoft Dataverse como a 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. Assim, ele tende a ser mais rápido do que outras fontes de dados. Para obter mais informações, consulte Fluxo de chamada de dados durante a conexão com o Microsoft Dataverse.

Verificar configurações de tabela personalizada: se tabelas personalizadas forem usadas no Dataverse, a configuração de segurança adicional poderá ser necessária para que os usuários exibam os registros com aplicativos de tela. Para obter mais informações, consulte: Conceitos de segurança no Dataverse, Configurar segurança do usuário para recursos em um ambiente e Direitos de acesso e privilégios.

Excel

O conector do Excel permite que um aplicativo de tela se conecte a uma tabela em um arquivo do Excel. No entanto, esse conector tem limitações em comparação com outras fontes de dados. Por exemplo, ele restringe o aplicativo de tela ao carregamento de dados da tabela apenas até 2.000 registros por causa de funções delegáveis limitadas. Para carregar mais de 2.000 registros, particione os dados em diferentes tabelas de dados como outras fontes de dados.

Usar o novo conector do Excel: não se esqueça de usar o novo conector do Excel – Excel Business Online. Ele possibilita acesso multiusuário e lida melhor com problemas de contenção.

Usar somente as colunas das quais você precisa de listas de dados grandes no Excel: um aplicativo poderá apresentar lentidão se o arquivo do Excel tiver muitas tabelas de dados ou tabelas com um volume imenso de dados em diversas colunas. Para garantir que o aplicativo não seja afetado por esse problema, defina apenas as colunas das quais você precisa na tabela de dados em um arquivo do Excel.

Observe as limitações do Excel como um banco de dados. 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 maneira como se um usuário estivesse alterando diretamente dados em um arquivo do Excel. Se tiver muitas leituras, mas menos operações de atualização, o aplicativo poderá funcionar bem. No entanto, se o aplicativo exigir 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. Isso também depende dos dados que estão sendo manipulados. Diversos outros aspectos também afetam o desempenho do aplicativo, como a sobrecarga da rede ou o dispositivo do usuário.

Levar em consideração as diferenças em localização geográfica: a localização geográfica dos dados e a distância das localizações dos clientes podem ser um problema de desempenho. Esse problema poderá ser amplificado se um cliente móvel tiver uma largura de banda limitada.