Depuração e Aprimoramento de Desempenho

Ferramentas para Desenvolvedor do Chrome

Chrome DevTools é um conjunto de ferramentas de desenvolvedor web construídas diretamente no navegador Google Chrome. Usando o DevTools do Chrome, você pode diagnosticar problemas em App Builder para solicitações que não estão sendo respondidas ou tratadas corretamente, registre um arquivo HAR que pode ser usado para solução de problemas e ajude a identificar problemas com tempos de carregamento de páginas.

O Chrome DevTools também fornece ferramentas para você capturar capturas de tela, emular a experiência de um usuário móvel e analisar solicitações feitas pela página conforme ela carrega para identificar áreas específicas que afetam o tempo de carregamento da página.

Identificando Códigos de Erro HTTP com o Chrome

O Chrome DevTools permite que você visualize e filtre rapidamente códigos de erro HTTP para ajudar a isolar e identificar um erro com an App Builder solicitação de aplicativo que não está sendo respondida ou tratada corretamente. Os códigos de status de resposta HTTP indicam se uma solicitação HTTP específica foi concluída com sucesso.

Na aba Network do Chrome DevTools, você pode filtrar rapidamente as informações resultantes clicando nos cabeçalhos das colunas. Aqui, você pode clicar em Status para visualizar os resultados do código HTTP e identificar quaisquer tarefas que não estejam retornando um resultado 200 OK.

No exemplo da captura de tela, na aba Chrome DevTools Network, vemos que a página do aplicativo está exibindo mensagens de erro 500 Internal Server Error e 504 Gateway Timeout. As informações contidas na coluna Name deste resultado ajudam a definir onde em App Builder este erro está sendo iniciado.

Aqui está uma lista dos resultados de código de erro HTTP mais comuns:

• 301 Movido permanentemente
• 302 Encontrado
• 307 Redirecionamento temporário
• 308 Redirecionamento permanente
• 400 Solicitação inválida = Erro do cliente
• 401 Não autorizado = Erro do cliente
• 403 Proibido = Erro do cliente
• 404 Não encontrado = Erro do cliente
• 405 Método não permitido = Erro do cliente
• 500 Erro interno do servidor = Erro do servidor
• 502 Gateway inválido = Erro do servidor
• 503 Serviço indisponível = Erro do servidor
• 504 Tempo limite do gateway = Erro do servidor

Gerando um Arquivo Har com o Chrome

Ao solucionar problemas complexos App Builder problemas, ter um arquivo HAR gravado e gerado a partir das ferramentas do Chrome Web Developer pode ser útil e/ou solicitado por an App Builder desenvolvedor para diagnosticar e resolver problemas mais a fundo. Um arquivo HAR captura um log de solicitações de rede e atividade no momento em que o problema em questão está acontecendo. Especificamente, um HAR é um formato de arquivo compactado em JSON para registro da interação de um navegador da web com um site.

Para Gerar um Arquivo Har:

1. Abra o Google Chrome e vá para o App Builder página onde o problema está acontecendo
2. Na barra de menu do Chrome, selecione Exibir > Desenvolvedor > Ferramentas do desenvolvedor
3. No painel aberto na parte inferior da tela, selecione a aba Rede
4. Procure um botão vermelho redondo Record no canto superior esquerdo da aba Network e certifique-se de que ele esteja vermelho. Se estiver cinza, clique nele uma vez para começar a gravar.
5. Marque a caixa ao lado de Preservar log
6. Clique no botão Limpar para limpar todos os logs existentes na aba Rede

7. Agora tente reproduzir o problema que você estava enfrentando antes, enquanto as solicitações de rede estão sendo gravadas

   

8. Depois de reproduzir o problema, clique com o botão direito do mouse na grade de solicitações de rede, selecione Salvar como HAR com conteúdo e salve o arquivo no seu computador

Para obter mais informações: consulte "Comece a analisar o desempenho da rede no Chrome DevTools" https://developers.google.com/web/tools/chrome-devtools/network-performance/

Identificando Problemas de Desempenho com o Chrome

As ferramentas do Chrome DevTools podem ajudar a identificar problemas de desempenho em seu App Builder app. Se você navegar primeiro para a página onde está enfrentando um problema de desempenho, você pode então abrir o DevTools e dar uma olhada na aba Network e classificar na coluna Time. Classifique para que você possa ver quais solicitações estão levando mais tempo. As colunas Name e Initiator correspondentes fornecem informações adicionais sobre a solicitação originada do App Builder aplicativo.

Observe que se nos resultados da aba Rede você descobrir que as solicitações chamadas filter? estão ocupando a maior parte do tempo de carregamento da página, isso indica que provavelmente você precisa otimizar o Objeto de Negócio correspondente.

Business Objects (ou Data Objects) podem ser uma fonte de tempos de carregamento de página lentos. Se você identificar que uma solicitação de execução mais longa se origina de um Business Object, consulte a próxima seção descrevendo os motivos pelos quais um Data Object é lento e opções para melhorar a velocidade.

Motivos pelos Quais um Objeto de Negócios é Lento e Opções para Melhorar a Velocidade

Dependendo da forma como são configurados, os Objetos de Negócios (também chamados de Objetos de Dados) podem ser uma causa de App Builder problemas de desempenho do aplicativo ou lentidão. Motivos específicos pelos quais um Objeto de Negócios pode ser lento incluem:

• A lógica SQL contém muitas subconsultas
• Colunas desnecessárias são usadas na lógica
• Cláusulas Where não estão usando instruções amigáveis ao índice
• Índices não são definidos em uma Tabela(s) que um Objeto de Dados está usando
• Índices redundantes em Tabela(s) sendo referenciados pela lógica SQL
• Junção em Colunas calculadas
• O uso do índice pode ser perdido devido à lógica em execução por meio de funções
• O campo binário é incluído quando o campo binário não está sendo usado por um Painel
  • Incluir somente campos binários em Objetos de Negócios se forem usados como um controle de arquivo
  • Vale a pena criar Objetos de Negócios especificamente para uso em Painéis onde um arquivo é carregado/baixado
• Todas as Colunas em um Objeto de Negócios serão carregadas por App Builder para as seguintes condições:
  • Formatação condicional existe
  • Se um campo tiver Substituição de suporte habilitada
  • Se um painel tiver quaisquer Regras de visibilidade não estáticas

Objetos de negócios ainda podem causar tempos de carregamento lentos com páginas de aplicativos, mesmo se os 'Resultados' do Objeto de negócios resultantes carregarem rapidamente. Verifique se há coisas na sua página de aplicativo que afetam a velocidade, como classificação, caixas de listagem ou outras configurações da Camada de IU que podem causar tempos de carregamento de página mais lentos.

Achatamento de Consultas SQL

Se você identificou que um Objeto de Negócio específico está causando problemas de desempenho, pode haver uma oportunidade de melhorar a lógica SQL e potencialmente simplificar a consultar.

• Na maioria das vezes você deve reutilizar subconsultas
• Às vezes, uma consultar pode se tornar tão grande com subconsultas aninhadas que fica lenta – somente então ela deve ser revisada e reescrita
• Achatar a consultar (removendo subconsultas desnecessárias) geralmente melhora o desempenho
• Pode examinar o plano de execução e os índices

Removendo Colunas Não Utilizadas

Muitas vezes, consultas com problemas de desempenho usam colunas desnecessárias na lógica SQL.

• Frequentemente descobrimos que consultas com problemas de desempenho têm subconsultas que selecionam muito mais dados do que os usados pela consultar externa
• A remoção dessas colunas (particularmente as colunas que são calculadas) melhorará o desempenho
• Use a Regra de Cópia e comece a fazer alterações
• Cronometre quanto tempo "Results" leva para retornar. Também cronometre quanto tempo para retornar "Load more rows".

Declarações Amigáveis de Índice em Cláusulas WHERE

A Cláusula Where define a condição de busca de uma instrução SQL e, portanto, cai no domínio funcional central de um índice: encontrar dados rapidamente. Uma Cláusula Where mal escrita é frequentemente a culpada por uma consultar SQL de execução lenta. Uma Cláusula Where deve ser eficiente e incluir o(s) índice(s) correto(s).

Ruim (os índices não serão usados):

• Onde LOWER(FirstName) como '%Bob%
• Onde NOW() > DATEADD(minutos,60,HoraInício)

Bom (índices utilizados):

• Onde FirstName como 'Bob%'
• Onde DateAdd(minutos,-60,AGORA()) > HoraInício

O SQL Server tem modo de rastreamento e utilitários de plano de consultar que você pode executar para ver se os índices estão sendo usados.

Configurações para Melhorar o Desempenho

Esta seção ilustrará as configurações em App Builder que impactam o desempenho. Evite pesquisar/filtrar/classificar em colunas em tabelas grandes que não são indexadas – quando consultas lentas são detectadas e índices não são uma opção.

No nível do Painel, habilitar Support Download e ter Simple Search On, e configurado como Indexed Only pode ajudar a melhorar o desempenho.

…FirstName like 'Bob%'…
Will match: "Bob Smith"
Will not match: "Mr Bobert"

Índices e o Que Deve Ser Indexado

Em SQL, um índice é usado para acelerar o desempenho de consultas, ajudando a buscar seus dados mais rapidamente do SQL Server. Isso é obtido reduzindo o número de páginas de dados do banco de dados que precisam ser visitadas/varridas. Ao pensar em índices em App Builder objetos de Dados, você precisa de índices suficientes para acelerar suas consultas SELECT e, ao mesmo tempo, não deve criar índices redundantes que poderiam potencialmente tornar suas operações UPDATE/DELETE mais lentas.

Arquiteturas de índice são classificadas como agrupadas ou não agrupadas. Índices agrupados são índices cuja ordem das linhas nas páginas de dados corresponde à ordem das linhas no índice. É por isso que apenas um índice agrupado pode existir em uma determinada tabela, enquanto muitos índices não agrupados podem existir na tabela.

Em App Builder, Os índices são criados em objetos Table. Em geral, cada tabela deve ter um índice clusterizado para permitir uma pesquisa eficiente dos dados nessa tabela. Quando uma tabela não tem um valor Index, isso pode contribuir para diminuir a velocidade de um aplicativo. Certifique-se de que a chave primária para cada tabela e quaisquer colunas de chave exclusivas que existam sejam indexadas. Ao considerar a modificação de índices em App Builder, tenha em mente os seguintes pontos-chave:

• Você quer equilibrar a criação de índices com o impacto no desempenho que isso causará em instruções de inserção/atualização. Adicionar índices acelerará as consultas, mas tornará a inserção/atualização/exclusão mais lenta.
• Você também precisa considerar a indexação de colunas que você usa para ordenar e aquelas que você usa em uma expressão de agrupamento. Você pode se beneficiar da indexação das colunas que as funções MIN(), MAX(), COUNT(), SUM() e AVG() usam para agregar os dados
• Você pode aproveitar os "índices de cobertura", onde você tem um índice maior que pode ser aproveitado por consultas que usam subconjuntos das colunas.
  • A ordem das colunas no índice é importante
  • A recomendação é que as colunas de desigualdade venham depois das colunas de igualdade em seus índices de cobertura

Ferramentas de Índice Ausentes

Existem utilitários e consultas do SQL Server que podem ser aproveitados para ajudar no processo de revisão de índices. As visualizações de gerenciamento dinâmico (DMVs) são utilitários do SQL Server que retornam informações de estado do servidor e podem ser usadas para monitorar a saúde do seu servidor de banco de dados e diagnosticar problemas. As DMVs fornecem uma ótima visão sobre o que está acontecendo dentro do SQL Server. Executá-las requer a permissão VIEW DATABASE STATE no banco de dados em questão.

Você pode identificar índices ausentes em suas consultas SQL principalmente de três maneiras:

• Executando o Database Engine Tuning Advisor
• Executando visualizações de gerenciamento dinâmico de índice ausente
• O SQL Server Engine exibe índices ausentes quando você gera Planos de Execução no SSMS

A seguir estão três consultas SQL frequentemente usadas para ajudar a identificar problemas com índices:

FindingLongRunningQueries.sql
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT TOP 20
CAST(qs.total_elapsed_time / 1000000.0 AS DECIMAL(28, 2))
AS [Total Duration (s)]
, CAST(qs.total_worker_time * 100.0 / qs.total_elapsed_time
AS DECIMAL(28, 2)) AS [% CPU]
, CAST((qs.total_elapsed_time - qs.total_worker_time)* 100.0 /
qs.total_elapsed_time AS DECIMAL(28, 2)) AS [% Waiting]
, qs.execution_count
, CAST(qs.total_elapsed_time / 1000000.0 / qs.execution_count
AS DECIMAL(28, 2)) AS [Average Duration (s)]
, SUBSTRING (qt.text,(qs.statement_start_offset/2) + 1,
((CASE WHEN qs.statement_end_offset = -1
THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2) + 1) AS [Individual Query]
, qt.text AS [Parent Query]
, DB_NAME(qt.dbid) AS DatabaseName
, qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qs.total_elapsed_time > 0
ORDER BY qs.total_elapsed_time DESC

IdentifyMostImportantMissingIndexes.sql
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT TOP 20
    ROUND(s.avg_total_user_cost *s.avg_user_impact*  (s.user_seeks + s.user_scans),0) AS [Total Cost]
 , d.[statement] AS [Table Name]
 , equality_columns
 , inequality_columns
 , included_columns
FROM sys.dm_db_missing_index_groups g
    INNER JOIN sys.dm_db_missing_index_group_stats s
        ON s.group_handle = g.index_group_handle
    INNER JOIN sys.dm_db_missing_index_details d
        ON d.index_handle = g.index_handle
WHERE d.database_ID = DB_ID()
ORDER BY`[Custo total] `DESC

IdentityUnusedIndexes.sql
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT
    DB_NAME() AS DatabaseName
 , SCHEMA_NAME(o.Schema_ID) AS SchemaName
 , OBJECT_NAME(s.[object_id]) AS TableName
 , i.name AS IndexName
 , s.user_updates
 , s.system_seeks + s.system_scans + s.system_lookups AS [System usage]
INTO    #TempUnusedIndexes
FROM    sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i
        ON s.[object_id] = i.[object_id]
        AND s.index_id   = i.index_id
    INNER JOIN sys.objects o
        ON i.object_id   = O.object_id
WHERE     1=2

EXEC sp_MSForEachDB 'USE [?];
INSERT INTO #TempUnusedIndexes
SELECT TOP 20
    DB_NAME() AS DatabaseName
 , SCHEMA_NAME(o.Schema_ID) AS SchemaName
 , OBJECT_NAME(s.[object_id]) AS TableName
 , i.name AS IndexName
 , s.user_updates
 , s.system_seeks + s.system_scans + s.system_lookups
    AS [System usage]
FROM    sys.dm_db_index_usage_stats s
    INNER JOIN sys.indexes i
        ON s.[object_id] = i.[object_id]
        AND s.index_id = i.index_id
    INNER JOIN sys.objects o ON i.object_id = O.object_id
WHERE     s.database_id = DB_ID()
AND     OBJECTPROPERTY(s.[object_id], ''IsMsShipped'') = 0
AND     s.user_seeks = 0
AND     s.user_scans = 0
AND     s.user_lookups = 0
AND     i.name IS NOT NULL
ORDER BY s.user_updates DESC'

SELECT     TOP 20 *
FROM     #TempUnusedIndexes
ORDER BY`[atualizações do usuário] `DESC
DROP TABLE #TempUnusedIndexes

Usando Instrução SQL de Logs e Otimizador de Índice

Depois de identificar um Objeto de Negócios com problemas de desempenho, você pode recuperar a lógica da instrução SQL do App Builder logs e execute-os por meio de um utilitário otimizador de índice para identificar áreas de melhoria. Isso pode resultar na identificação de índices a serem adicionados, por exemplo.

Para recuperar a lógica da instrução SQL, navegue no aplicativo até a página onde o Objeto de Negócios está sendo usado. A partir daqui:

1. Vá para IDE > Monitoramento
2. Clique em Logs do Banco de Dados no Menu
3. Clique no botão Editar Configuração
4. Clique em Editar

5. Na seção Configuração do Log de Memória, defina a Gravidade Mínima como Rastreamento.

   Importante

   Sempre redefina o valor de Severidade Mínima de volta para Desligado quando terminar de capturar informações de log.

6. Clique no botão Salvar

7. Agora você deve estar visualizando a tela Logs Rápidos em App Builder, que consiste em 500 linhas de dados de log (a menos que você modifique esse valor de 500). Percorra os dados de log até localizar a lógica da instrução SQL que você está procurando.

8. Copie toda a lógica da instrução SQL, começando com SELECT. Por exemplo:

   

9. Clique no botão Editar configuração

10. Clique em Editar na tela Configuração de Log
11. Na seção Configuração do Log de Memória, defina a Gravidade Mínima como Desligado
12. Inicie o SQL Server Management Studio
13. Conecte-se à sua conexão de banco de dados
14. Existem alguns caminhos diferentes que você pode aproveitar no SQL Server Management Studio para otimizar melhor parte da lógica de instruções SQL que seu aplicativo está usando
15. Você pode clicar no botão Nova consulta, definir o Banco de dados disponível para o banco de dados correspondente ao aplicativo que você está revisando

16. Insira a seguinte sintaxe de consultar, que é uma consultar para encontrar as 10 principais consultas SQL que usam mais recursos (leituras, gravações, tempo de trabalho (CPU), etc.):

    

17. Clique no botão Executar

18. Os resultados exibirão as 10 principais consultas SQL que estão levando mais tempo para retornar informações no seu aplicativo. Observe que a segunda entrada em nossa captura de tela de exemplo retorna a mesma consultar que identificamos acima (SELECT TOP 2…).

    

19. Clique no botão Nova consulta na barra de ferramentas

20. Insira a lógica da instrução SQL que você copiou do App Builder logs

21. Selecione o banco de dados correspondente no menu de seleção de Banco de Dados Disponível

    

22. Se você estiver usando o banco de dados SQL Server (o SQL Express não oferece suporte a isso), você pode clicar com o botão direito do mouse dentro do painel SQL Query e selecionar Analyze Query no Database Engine Tuning Advisor. Aqui você também pode aproveitar o utilitário de plano de execução, que mapeará a viagem que a instrução SQL faz pelo banco de dados do aplicativo e ajudará a identificar áreas que podem estar levando muito tempo para ajuste.

O ajuste de banco de dados é um conjunto de habilidades técnicas e complexas, requer as permissões corretas para acessar e visualizar bancos de dados e deve ser feito de forma metódica, cuidadosa e com testes rigorosos durante todo o processo para garantir que o resultado final seja positivo.

Recursos

• Ajuste de desempenho de consulta (SQL Server Compact): https://technet.microsoft.com/en-us/library/ms172984(v=sql.110).aspx.aspx)
• SQL Server 2017 - "Exibições e funções de gerenciamento dinâmico relacionadas a índice (Transact-SQL)" da Microsoft: https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/index-related-dynamic-management-views-and-functions-transact-sql?view=sql-server-2017