Partilhar via


Outras considerações de desempenho

Em adição aos quatro princípios-chave do desempenho, existem vários outros motivos possíveis para o mau desempenho, normalmente, devido a fatores externos.

Considere as diferenças nos browsers, dispositivos e locais dos Clientes

As aplicações de tela podem ser usadas em diferentes dispositivos, browsers e locais com diferentes condições de rede. À medida que o cliente Power Apps é executado, certifique-se de que utiliza browsers suportados modernos e atualizados. 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 diverge por plataforma. Estas diferenças podem ter um grande impacto no tempo de carregamento de dados para grandes conjuntos de dados.

Considere as diferenças na Localização geográfica do gateway de dados no local e o ambiente

Os utilizadores podem aceder a aplicações de tela globalmente. No entanto, recomenda-se localizar a origem de dados perto da maioria dos seus utilizadores. Por exemplo, quando a sua aplicação acede ao seu gateway de dados no local, é melhor colocar o gateway próximo dos utilizadores que acedem à aplicação com mais frequência.

Problemas gerais do lado do servidor

O baixo desempenho pode ser causado por problemas no servidor de origem dos dados. Isto pode ocorrer por vários motivos. Pode usar a ferramenta de monitorização para avaliar o problema específico ao medir as temporizações de chamada de dados.

Possíveis problemas de estrangulamento na origem de dados

Existem muitas causas possíveis de estrangulamentos no origem de dados. Normalmente, algumas tabelas na origem de dados estão no centro da atividade para muitas consultas. As consultas podem ser lentas se:

  • A origem de dados está ausente ou possuir índices incorretos.
  • A consulta está a unir grandes quantidades extraordinariamente grandes de dados no servidor.
  • A consulta requer uma ANÁLISE de tabela, por exemplo, o operador In, em vez de usar um índice como StartsWith.
  • A máquina de back-end que hospeda a origem de dados tem pouco recursos.
  • A instância de back-end SQL tem bloqueios, impasses ou contenção de recursos.
  • O gateway de dados no local está em mau estado de funcionamento.
  • O gateway de dados no local deve ser ampliado.

Quando estes problemas ocorrerem, sintonize a origem de dados back-end para evitar que o desempenho da aplicação fique lento.

Origens de dados específicas

Base de Dados SQL do Azure

É importante selecionar o escalão certo para os seus requisitos de negócio. Para mais informações, consulte documentação da Base de Dados SQL do Azure. Um escalão mais baixo tem 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.

SharePoint

O conector do SharePoint pode ser usado para criar aplicações que usam dados de Listas do SharePoint. Eis alguns problemas comuns de desempenho e resoluções para o SharePoint:

Evite demasiadas colunas de procura dinâmicas: 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. Para evitar isto, não utilize em excesso as colunas de procura dinâmicas no SharePoint. Por exemplo, pode usar colunas estáticas para manter pseudónimos de e-mail, ou nomes das pessoas.

Use cuidadosamente a coluna de imagens e o 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.

Considere dividir 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.

Dataverse

Quando utiliza o Microsoft Dataverse como origem de dados, os pedidos de dados vão diretamente para a instância do ambiente sem passar pela API Management do Azure. Portanto, tende a ser mais rápida do que outras origens de dados. Para mais informações, consulte Fluxo de chamada de dados ao ligar-se ao Microsoft Dataverse.

Verifique as configurações de tabela personalizada: se as tabelas personalizadas são utilizadas no Dataverse, poderá ser necessária configuração adicional de segurança para que os utilizadores vejam os registos com aplicações de tela. Para mais informações, consulte Conceitos de segurança no Dataverse, Configurar a segurança de utilizador para recursos num ambiente e Direitos de acesso e privilégios.

Excel

O conector do Excel permite que uma aplicação de tela se ligue a uma tabela num ficheiro do Excel. No entanto, este conector tem limitações em comparação com outras origens de dados. Por exemplo, restringe a aplicação de tela a carregar dados da tabela apenas até 2.000 registos devido a funções delegáveis ​​limitadas. Para carregar mais de 2.000 registos, particione os seus dados em tabelas de dados diferentes como outras origens de dados.

Use o novo conector do Excel: certifique-se de que usa o novo conector do Excel — Excel Business Online. Permite acesso de vários utilizadores e lida melhor com problemas de contenção.

Use apenas as colunas de que necessita das listas de dados grandes no Excel: uma aplicação pode ter um desempenho lento se o ficheiro do Excel que tem demasiadas tabelas de dados, ou tabelas de dados que contêm um imenso tamanho de dados em várias colunas. 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.

Note as limitações do Excel como uma base de dados. 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 diretamente. Se a aplicação tiver um elevado número de operações de leitura, mas menos operações de atualização, poderá ter um bom desempenho. No entanto, se a aplicação requer transações pesadas, poderá afetar negativamente o desempenho da aplicação. Não há um valor de limiar específico para o número de transações. 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.

Considere as diferenças na localização geográfica: a localização geográfica dos dados e a respetiva distância das localizações dos clientes podem ser um problema de desempenho. Este problema pode ser amplificado se um cliente móvel tiver largura de banda limitada.