Otimizando o desempenho dos aplicativos

O desempenho dos aplicativos pode ser aprimorado com a redução do seu tamanho, com modelos de dados simplificados e por meio do uso estratégico de análises de conjuntos. Esta seção ajudará você a evitar problemas de desempenho, apontando áreas nas quais o desempenho pode ser afetado e como você pode avaliar e monitorar o desempenho do aplicativo.

Complexidade do aplicativo

Essas são categorias abertas que podem ajudar no diagnóstico de problemas. Os aplicativos mais complexos apresentam o menor desempenho.

Aplicativos simples:

Não incluem análises complexas de conjuntos ou comandos If().
Não incluem tabelas grandes.
Têm um modelo de dados simples.
Contêm cálculos simples.
Podem ter grandes volumes de dados.

Aplicativos moderados:

Têm um modelo de dados com muitas tabelas, mas seguem práticas recomendadas.
Usam análise de conjuntos e vários comandos If().
Têm tabelas grandes ou amplas em pastas (15 colunas ou mais).

Aplicativos complexos:

Têm um modelo de dados muito complexo.
Conectam-se a grandes volumes de dados.
Contêm cálculos, gráficos e tabelas complexos.

Detalhes do aplicativo

É necessário considerar seu ambiente de hardware em relação ao tamanho do aplicativo, pois ele afeta o desempenho da sua implementação do Qlik Sense. Por exemplo, se você não otimizar seus aplicativos, talvez eles exijam mais recursos de hardware.

O monitoramento do tamanho do aplicativo ajudará você a:

Entender o desempenho atual.
Entender o impacto da implementação de um novo aplicativo sobre o desempenho.
Entender o impacto da modificação de um aplicativo existente sobre o desempenho.
Resolver problemas de desempenho.
Planejar o crescimento futuro.

A Qlik fornece ferramentas que podem ajudar você a avaliar seus aplicativos. Para obter mais informações, consulte: Desempenho e escalabilidade no Qlik Sense Enterprise (somente em inglês).

Estes são os elementos básicos de aplicativos que podem afetar o desempenho:

Detalhes de aplicativos que podem afetar o desempenho
Recurso	Descrição
Tamanho do disco do aplicativo (MB)	É possível encontrar o tamanho do aplicativo no QMC. Acesse Aplicativos e abra o Seletor de coluna no lado direito, ao lado de Ações. Clique no botão de opção ao lado de Tamanho do arquivo (MB). Se estiver usando o Qlik Sense Desktop, você poderá encontrar o tamanho do aplicativo em Windows Explorer. A pasta padrão é %USERPROFILE%\Documents\Qlik\Sense\Apps. A pasta Apps lista todos os nomes de aplicativos e tamanhos de arquivo.
Tamanho do aplicativo em RAM (GB)	É possível determinar a pegada de RAM base de um aplicativo fazendo o seguinte: Reiniciando o servidor do Qlik Sense. Observando o uso atual de RAM. Abrindo o aplicativo Qlik Sense. Registrando a diferença na RAM. Você poderá usar o App Metadata Analyzer para encontrar essa métrica se estiver usando o Qlik Sense June 2018 ou versão posterior. Para obter mais informações, veja App Metadata Analyzer (somente em inglês).
Total de linhas do aplicativo (M)	É possível usar campos do sistema para calcular o total de linhas. Crie um KPI com a medida Sum($Rows). Para obter mais informações, consulte Campos do sistema.
Total de campos do aplicativo	É possível usar campos do sistema para calcular o total de campos. Crie um KPI com a medida Sum($Fields). Para obter mais informações, consulte Campos do sistema.
Total de tabelas do aplicativo	É possível usar campos do sistema para calcular o total de tabelas. Crie um KPI com a medida Count(DISTINCT $Table). Para obter mais informações, consulte Campos do sistema.

Monitorando seu aplicativo

O Qlik Management Console (QMC) fornece aplicativos para monitorar o desempenho e o uso do sistema no Qlik Sense Enterprise on Windows:

O aplicativo Operations Monitor fornece informações sobre utilização de hardware, como memória do servidor e uso da CPU, usuários ativos e atividades de tarefas de carregamento. Ele também fornece informações resumidas e detalhadas sobre erros, avisos e atividades de log no ambiente de servidor do Qlik Sense.
O aplicativo License Monitor rastreia o uso de licenças e facilita o monitoramento de alterações na alocação de licenças.
O aplicativo Log Monitor apresenta quase todos os dados de log disponíveis e permite análises de tendências e solução de problemas.
O aplicativo Sessions Monitor mostra dados de log sobre o uso de aplicativos.
O aplicativo Reloads Monitor apresenta informações detalhadas sobre dados de carregamento, tanto do QMC quanto de aplicativos abertos no hub.
O aplicativo Sense System Performance Analyzer exibe o desempenho do Qlik Sense em todos os nós.
O aplicativo Sense Connector Logs Analyzer fornece ideias de uso e erros de conectores específicos da Qlik.
O aplicativo App Metadata Analyzer fornece uma visão holística de todos os seus aplicativos Qlik Sense, incluindo detalhes em nível granular de um modelo de dados de aplicativos e sua utilização de recursos.

Para obter mais informações, consulte Monitorando um site do Qlik Sense Enterprise on Windows (somente em inglês).

Grandes volumes de dados

Você pode empregar estas estratégias de arquitetura ao se conectar a grandes volumes de dados.

Segmentação

É possível segmentar QVDs por dimensões, como período, região ou nível de agregação. Por exemplo, você pode ter:

Um QVD que contém dados dos dois anos mais recentes.
Um QVD que contém dados históricos além de dois anos.
Um QVD que contém todos os dados agregados em um nível mais alto. Por exemplo, por mês em vez de data, ou por país em vez de clientes individuais.
Um QVD grande com todos os dados, que são usados apenas por um pequeno subconjunto de usuários.

Os aplicativos podem ser segmentados de maneira semelhante. Aplicativos menores atenderão às necessidades analíticas da maioria dos usuários. Isso economiza memória.

Você também pode ter vários aplicativos focados em diferentes regiões. Dessa forma, os usuários não abrirão um aplicativo com dados nos quais não estejam interessados ou aos quais não tenham direitos de acesso. Os dados não acessíveis via Section Access ainda afetam a memória.

Geração de aplicativos sob demanda (ODAG)

Aplicativos Qlik Sense sob demanda oferecem aos usuários exibições agregadas de repositórios de big data. Eles podem identificar e carregar subconjuntos relevantes dos dados para análises detalhadas.

Da perspectiva do usuário, existem dois aplicativos:

Um carrinho de compras com dados agregados.
Um aplicativo modelo vazio usado para exibir detalhes.

O usuário faz seleções no aplicativo de carrinho de compras. Depois que um limite é atingido, é criado um script LOAD personalizado que preenche o aplicativo modelo com os detalhes solicitados. Para obter mais informações, consulte Gerenciando big data com aplicativos on-demand.

Desempenho do modelo de dados

Estes são indicadores que podem afetar o desempenho do modelo de dados. Cada um deles é uma prática recomendada que melhorará a utilidade do aplicativo.

Práticas recomendadas de desempenho do modelo de dados
Ação	Descrição
Chaves sintéticas removidas	O Qlik Sense cria chaves sintéticas quando duas ou mais tabelas de dados têm dois ou mais campos em comum. Isso pode significar que há um erro no script ou no modelo de dados. Para diagnosticar chaves sintéticas, consulte Chaves sintéticas.
Referências circulares removidas do modelo de dados	Referências circulares ocorrem quando dois campos têm mais de uma associação. O Qlik Sense tentará resolvê-las, alterando a conexão com uma das tabelas. No entanto, todos os avisos de referência circular devem ser resolvidos. Consulte Entendendo e solucionando as referências circulares.
Granularidade apropriada dos dados	Você deve carregar apenas os dados necessários. Por exemplo: um grupo de usuários precisa apenas de dados divididos por semana, mês e ano. É possível carregar os dados agregados ou agregar esses dados no script de carregamento para economizar memória. Se um usuário precisar visualizar dados em um nível mais baixo de granularidade, você poderá usar o ODAG ou o encadeamento de documentos.
QVDs usados sempre que possível	Um QVD é um arquivo que contém uma tabela de dados exportada do Qlik Sense. Esse formato de arquivo é otimizado para velocidade ao ler dados de um script, mas ainda é muito compacto. A leitura de dados de um arquivo QVD é geralmente de 10 a 100 vezes mais rápida do que a leitura de outras fontes de dados. Para obter mais informações, consulte: Trabalhando com arquivos QVD.
Arquivos QVD otimizados no carregamento	Os arquivos QVD podem ser lidos em dois modos, padrão (rápido) e otimizado (mais rápido). O modo selecionado é determinado automaticamente pelo mecanismo de script. Existem algumas limitações em relação a carregamentos otimizados. É possível renomear campos, mas qualquer uma dessas operações resultará em um carregamento padrão: Quaisquer transformações nos campos que são carregadas. Usando uma cláusula where, fazendo com que Qlik Sense descompacte os registros. Usando o Mapa em um campo carregado.
Carregamentos incrementais otimizados	Se o seu aplicativo se conectar a uma grande quantidade de dados provenientes de bancos de dados atualizados continuamente, recarregar todo o conjunto de dados pode ser muito demorado. Em vez disso, você deve usar o carregamento incremental para recuperar registros novos ou alterados do banco de dados. Para obter mais informações, consulte Carregando registros novos e atualizados com carregamento incremental.
Modelo Snowflake consolidado	Se você tiver um modelo de dados Snowflake, poderá reduzir o número de tabelas de dados ao unir algumas delas com o uso do prefixo Join ou outro mapeamento. Isso é especialmente importante para tabelas de fatos grandes. Uma boa regra é ter apenas uma tabela grande. Para obter mais informações, consulte Unir ou não unir.
Tabelas que possuem um pequeno número de campos são desnormalizadas	Se você tiver duas tabelas com poucos campos, uni-las poderá melhorar o desempenho. Para mais informações, consulte Próximas etapas em scripts.
Tabelas de pesquisa (folha) desnormalizadas com carregamentos de mapeamentos	Não use o prefixo Join se precisar adicionar apenas um campo de uma tabela a outra tabela. Você deve usar a função de consulta ApplyMap. Consulte Não una - use ApplyMap.
Carimbos de data/hora removidos ou dissociados do campo de data	Campos de data podem preencher espaço quando o carimbo de data/hora está presente, pois a representação da string é maior e o número de valores distintos também é maior. Se a precisão não for necessária para sua análise, você poderá arredondar o carimbo de data/hora para, por exemplo, a hora mais próxima usando Timestamp(Floor(YourTimestamp,1/24)) ou remover o componente de tempo completamente usando Date(Floor(YourTimestamp)). Se o carimbo de data/hora não for desejável, você poderá dissociá-lo da própria data. É possível usar a mesma função Floor() e, em seguida, criar um novo campo com a hora extraída, usando algo semelhante ao seguinte: Time(Frac(YourTimestamp)).
Campos desnecessários removidos do modelo de dados	Você deve carregar apenas os campos necessários no seu modelo de dados. Evite usar Load * e SELECT. Certifique-se de manter: Campos que são necessários para a sua análise. Campos que estão realmente sendo usados no aplicativo.
Tabelas de links evitadas ao lidar com grandes volumes de dados	Você deve usar tabelas de links sempre que possível. No entanto, se estiver lidando com grandes volumes de dados, tabelas concatenadas poderão superar tabelas de links.
Dimensões concatenadas divididas em novos campos	Você deve dividir dimensões concatenadas em campos separados. Isso reduz o número de ocorrências exclusivas de valores nos seus campos. Esse processo é semelhante a como carimbos de data/hora podem ser otimizados.
Comando AutoNumber usado sempre que possível	É possível criar um carregamento otimizado, carregando seus dados primeiramente de um arquivo QVD e depois usando o comando AutoNumber para converter valores em chaves de símbolos. Para obter mais informações, consulte AutoNumber.
Ilhas de dados evitadas	Ilhas de dados podem ser úteis, mas geralmente afetam o desempenho. Se estiver criando ilhas para valores de seleção, use variáveis.
QVDs são armazenados com base em períodos incrementais	Você deve armazenar QVDs em segmentos, como mensalmente. Esses QVDs mensais menores podem então oferecer suporte a muitos aplicativos diferentes que talvez não precisem de todos os dados.

Desempenho de pastas

Estas são práticas recomendadas que melhorarão o desempenho de pastas e visualizações.

Práticas recomendadas para o desempenho de pastas
Ação	Descrição
A função If() é evitada sempre que possível	Se a função If() for usada dentro de uma função de agregação, ela operará no nível do registro e será avaliada muitas vezes. Por exemplo, se você tiver 1000 registros em uma agregação, uma condição If() será avaliada 1000 vezes. Isso poderá gerar rapidamente um efeito cascata se você aninhar comandos. Em vez disso, use análises de conjunto. Um filtro de análise de conjunto é aplicado antes da agregação, resultando em uma resposta mais rápida. Essas respostas também podem ser armazenadas em cache via análise de conjuntos, o que não é possível com If(). Você também pode considerar outras funções e modificações no modelo de dados.
Campos de diferentes tabelas dentro de uma tabela de agregação são evitados sempre que possível.	Quando uma agregação é avaliada, o cálculo é executado em duas etapas: A primeira etapa é encontrar as combinações relevantes nas quais fazer o cálculo. Essa etapa tem um só encadeamento. A segunda etapa é realizar o cálculo. Essa etapa tem vários encadeamentos. A parte com encadeamento único pode afetar o desempenho consideravelmente. Um exemplo é quando existem vários campos dentro da agregação, como Sum(Quantity*ListPrice). Se Quantity estiver na tabela de fatos e ListPrice estiver na tabela de produtos mestre, primeiro o mecanismo precisará unir as duas tabelas para encontrar as combinações para poder começar a somar o produto. A união é a parte de encadeamento único, e a soma é parte de vários encadeamentos. Se ambos os campos forem encontrados na mesma tabela, nenhuma união será necessária, e a agregação será avaliada de maneira consideravelmente mais rápida.
Aggr() e funções Aggr() aninhadas são usadas minimamente	A função Aggr() afeta muito o desempenho. Seu uso incorreto pode gerar resultados imprecisos. Por exemplo, em uma tabela com dimensões que variam das dimensões dentro da função Aggr(). Para obter mais informações, consulte Quando o AGGR não deve ser usado?
A análise de conjuntos é usada sempre que possível	É possível usar a análise de conjuntos para definir um conjunto de valores de dados diferente do conjunto normal definido pelas seleções atuais. Para obter mais informações, consulte Análise de conjunto.
Comparações de strings evitadas sempre que possível	Comparações de strings não são tão eficientes quanto análises de conjuntos. Por exemplo, você deve evitar Match(), MixMatch(), WildMatch() e Pick(). Crie sinalizadores no script ou use a análise de conjunto como alternativa. Para obter mais informações, consulte Funções condicionais e Desempenho de agregações condicionais.
Condições de cálculo são usadas em objetos que contêm cálculos intensivos	Você pode ter visualizações com muitos registros quando não existem seleções. Como prática recomendada, adicione condições de cálculo aos objetos para que eles sejam renderizados somente depois que determinadas seleções forem feitas. Isso interrompe a criação de hipercubos muito grandes. Por exemplo: GetSelectedCount([Country])=1 OR GetPossibleCount([Country])=1. Nesse cenário, a visualização não será renderizada, a menos que o usuário selecione um único país ou faça outras seleções em que apenas um único país é possível.
Medidas são pré-calculadas no script sempre que possível	Qualquer medida que esteja no nível mais baixo de granularidade do modelo de dados deve ser calculada no script. Por exemplo, no mesmo registro de uma tabela, se você tiver Sales e Cost, será possível derivar a margem calculando Sales - Cost AS Margin. Você também poderá agregar outros valores antecipadamente se souber que eles não variarão com base na seleção ou que estão vinculados a um nível diferente de granularidade.
Tabelas têm menos de 15 colunas e têm condições de cálculo	Uma tabela com 15 colunas pode ser considerada ampla. Se as suas tabelas consistirem em muitos registros, você deverá usar condições calculadas no objeto da tabela, para que ele seja processado somente depois que determinadas seleções ou critérios forem atendidos. Se sua tabela for muito grande, considere o seguinte: Criar várias tabelas menores que são exibidas condicionalmente. Usar métodos para mostrar colunas condicionalmente. Manter suas tabelas limitadas apenas aos campos que são necessários para a sua análise.
As pastas não têm um número excessivo de objetos	Os objetos são calculados quando o usuário navega até a pasta. Sempre que um usuário fizer uma seleção nessa pasta, cada objeto será recalculado se esse estado atual não existir no cache. Se você tiver uma pasta com muitos gráficos, o usuário terá que esperar que cada objeto seja calculado em quase todas as seleções. Isso coloca uma carga significativa sobre o mecanismo. Como prática recomendada, siga o conceito de Dashboard/Analysis/Reporting (DAR) para desenvolver um aplicativo limpo e minimalista.Para obter mais informações, consulte Metodologia DAR.
Sinalizadores numéricos são otimizados no script para uso na análise de conjuntos	A análise de conjuntos com sinalizadores pode ser mais eficiente do que usar comparações ou a multiplicação de strings.
Itens mestre ou variáveis usados para expressões	Itens mestre permitem arrastar e soltar métricas controladas e garantir que as expressões sejam armazenadas em cache. Por exemplo, Sum(Sales) é diferente de SUM(Sales). Expressões são armazenadas em cache em nível de ortografia e formatação de maiúsculas e minúsculas e precisam corresponder literalmente para serem reutilizadas.

Esta página ajudou?

Se você encontrar algum problema com esta página ou seu conteúdo - um erro de digitação, uma etapa ausente ou um erro técnico - informe-nos como podemos melhorar!

Deixe seu feedback aqui