Depuração e aprimoramento de desempenho no Jitterbit App Builder

Ferramentas para desenvolvedor do Chrome

Chrome DevTools é um conjunto de ferramentas para desenvolvedor web integradas diretamente ao navegador Google Chrome. Usando o DevTools do Chrome, você pode diagnosticar problemas no App Builder com solicitações que não estão sendo respondidas ou processadas corretamente, gravar um arquivo HAR que pode ser usado para posterior solução de problemas e ajudar a identificar problemas com o tempo de carregamento das 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 impactam 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 em uma solicitação do App Builder 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 Rede 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 Rede do Chrome DevTools, vemos que a página do aplicativo está exibindo as mensagens de erro 500 Erro Interno do Servidor e 504 Tempo Limite do Gateway. As informações contidas na coluna Nome deste resultado ajudam a definir onde no App Builder esse erro está sendo iniciado.

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

301 Movido permanentemente
302 encontrados
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 do App Builder, ter um arquivo HAR registrado e gerado a partir das ferramentas do Chrome Web Developer pode ser útil e/ou solicitado por um desenvolvedor do App Builder para diagnosticar e resolver problemas mais aprofundadamente. Um arquivo HAR captura um log de solicitações e atividades de rede no momento em que o problema em questão está ocorrendo. Especificamente, um HAR é um formato de arquivo compactado em JSON para registrar a interação de um navegador da web com um site.

Para gerar um arquivo har:

Abra o Google Chrome e vá para a página do App Builder onde o problema está ocorrendo
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 o botão vermelho e redondo "Gravar" no canto superior esquerdo da aba"Rede" e certifique-se de que esteja vermelho. Se estiver cinza, clique nele uma vez para iniciar a gravação.
Marque a caixa ao lado de Preservar registro
Clique no botão Limpar para limpar todos os registros 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 em 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 no seu aplicativo App Builder. Se você navegar primeiro até a página onde está enfrentando o problema de desempenho, poderá abrir o DevTools e consultar a aba Rede e classificar pela coluna Tempo. Classifique para ver quais solicitações estão demorando mais. As colunas Nome e Iniciador correspondentes fornecem informações adicionais sobre a solicitação originada do aplicativo App Builder.

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

Objetos de Negócios (ou Objetos de Dados) podem ser uma fonte de lentidão no carregamento de páginas. Se você identificar que uma solicitação com execução mais longa se origina de um Objeto de Negócios, consulte a próxima seção, que descreve os motivos pelos quais um Objeto de Dados está lento e opções para melhorar a velocidade.

Razões pelas quais um objeto de negócios é lento e opções para melhorar a velocidade

Dependendo da configuração, os Objetos de Negócios (também conhecidos como Objetos de Dados) podem ser a causa de problemas de desempenho ou lentidão no App Builder. Motivos específicos pelos quais um Objeto de Negócios pode estar lento incluem:

A lógica SQL contém muitas subconsultas
Colunas desnecessárias são usadas na lógica
Onde as cláusulas não estão usando instruções amigáveis ao índice
Os índices não são definidos em uma ou mais tabelas que um objeto de dados está usando
Índices redundantes em tabelas sendo referenciados pela lógica SQL
Junção em colunas calculadas
O uso do índice pode ser perdido devido à lógica executada nas 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 comercial serão carregadas pelo App Builder para as seguintes condições:
- Existe formatação condicional
- Se um campo tiver Substituição de Suporte habilitada
- Se um painel tiver alguma regra de visibilidade não estática

Os Objetos de Negócios ainda podem causar lentidão no carregamento de páginas de aplicativos, mesmo que os "Resultados" resultantes do Objeto de Negócios carreguem rapidamente. Verifique se há algo na página do seu aplicativo que esteja afetando a velocidade, como classificação, caixas de listagem ou outras configurações da Camada de Interface do Usuário que possam causar lentidão no carregamento da página.

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 (remover 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 o tempo que "Resultados" leva para retornar. Também cronometre o tempo que "Carregar mais linhas" leva para retornar.

Instruçõ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, se enquadra no domínio funcional central de um índice: encontrar dados rapidamente. Uma Cláusula Where mal escrita costuma ser a culpada por uma consultar SQL lenta. Uma Cláusula Where deve ser eficiente e incluir o(s) índice(s) correto(s).

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

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

Bom (índices utilizados):

Onde Nome 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 do App Builder que afetam o desempenho. Evite pesquisar/filtrar/classificar em colunas de tabelas grandes que não estão indexadas - quando consultas lentas são detectadas e os índices não são uma opção.

No nível do painel, habilitar Suporte para download e ter a Pesquisa simples ativada e configurada como Somente indexado pode ajudar a melhorar o desempenho.

Nota

Ao pesquisar campos indexados, o 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 das consultas, ajudando a buscar seus dados mais rapidamente no SQL Server. Isso é alcançado reduzindo o número de páginas de dados do banco de dados que precisam ser visitadas/varridas. Ao pensar em índices em Objetos de Dados do App Builder, você precisa de índices suficientes para acelerar suas consultas SELECT e, ao mesmo tempo, não deve criar índices redundantes que possam potencialmente tornar suas operações de UPDATE/DELETE mais lentas.

As 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.

No App Builder, os índices são criados em objetos Table. De modo geral, cada tabela deve ter um índice clusterizado para permitir uma busca eficiente dos dados contidos nela. Quando uma tabela não possui um valor de índice, isso pode contribuir para a lentidão do aplicativo. Certifique-se de que a chave primária de cada tabela e quaisquer colunas de chave exclusivas existentes estejam indexadas. Ao considerar a modificação de índices no App Builder, lembre-se dos 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 das colunas que você usa para ordenar por 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 utilizados para auxiliar no processo de revisão de índices. As Exibições de Gerenciamento Dinâmico (DMVs) são utilitários do SQL Server que retornam informações sobre o estado do servidor e podem ser usadas para monitorar a integridade do seu servidor de banco de dados e diagnosticar problemas. As DMVs fornecem informações úteis 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 [Total Cost] 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 [user_updates] DESC
DROP TABLE #TempUnusedIndexes

Usando instrução SQL de logs e otimizador de índice

Após identificar um Objeto de Negócio com problemas de desempenho, você pode recuperar a lógica da instrução SQL dos logs do App Builder e executá-la em um utilitário otimizador de índice para identificar áreas que precisam de melhorias. 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ócio 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 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 no 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 procura.
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 ao seu banco de dados
Existem alguns caminhos diferentes que você pode utilizar 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 demorando mais para retornar informações no seu aplicativo. Observe que a segunda entrada na captura de tela do nosso 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 dos logs do App Builder
Selecione o banco de dados correspondente no menu de seleção de Banco de Dados Disponível
Se estiver usando um banco de dados SQL Server (o SQL Express não oferece suporte a ele), você pode clicar com o botão direito do mouse dentro do painel Consulta SQL e selecionar Analisar Consulta no Consultor de Otimização do Mecanismo de Banco de Dados. Aqui, você também pode utilizar o utilitário de plano de execução, que mapeará o trajeto da instrução SQL pelo banco de dados do aplicativo e ajudará a identificar áreas que podem estar demorando muito para serem ajustadas.

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