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.

Nota

Para baixar o Google Chrome: https://www.google.com/chrome/

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.

Guia de rede do Chrome

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

Nota

Para mais códigos de erro HTTP, consulte: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

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:¶

Abra o Google Chrome e vá para o App Builder página onde o problema está acontecendo
Na barra de menu do Chrome, selecione Exibir > Desenvolvedor > Ferramentas do desenvolvedor
No painel aberto na parte inferior da tela, selecione a aba Rede
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.
Marque a caixa ao lado de Preservar log
Clique no botão Limpar para limpar todos os logs existentes na aba Rede
Agora tente reproduzir o problema que você estava enfrentando antes, enquanto as solicitações de rede estão sendo gravadas
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.

Nota

Ao pesquisar campos indexados, App Builder gera consultas amigáveis ao índice:

…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:

Vá para IDE > Monitoramento
Clique em Logs do Banco de Dados no Menu
Clique no botão Editar Configuração
Clique em Editar
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.
Clique no botão Salvar
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.
Copie toda a lógica da instrução SQL, começando com SELECT. Por exemplo:
Clique no botão Editar configuração
Clique em Editar na tela Configuração de Log
Na seção Configuração do Log de Memória, defina a Gravidade Mínima como Desligado
Inicie o SQL Server Management Studio
Conecte-se à sua conexão de banco de dados
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
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
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.):
Clique no botão Executar
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…).
Clique no botão Nova consulta na barra de ferramentas
Insira a lógica da instrução SQL que você copiou do App Builder logs
Selecione o banco de dados correspondente no menu de seleção de Banco de Dados Disponível
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