Otimização do desempenho
OBSERVAÇÃOUm problema importante é o tempo que o site leva para responder às solicitações do visitante. Embora esse valor varie para cada solicitação, um valor de target médio pode ser definido. Quando esse valor puder ser obtido e mantido, ele poderá ser usado para monitorar o desempenho do site e indicar o desenvolvimento de possíveis problemas.
Os tempos de resposta almejados são diferentes nos ambientes de criação e publicação, refletindo as diferentes características do público-alvo:
Ambiente de criação
Esse ambiente é usado pelos autores que inserem e atualizam conteúdo. Ele deve atender a alguns usuários, cada um deles gerando um alto número de solicitações de desempenho intensivo ao atualizar páginas de conteúdo e os elementos individuais nessas páginas.
Ambiente de publicação
Esse ambiente contém conteúdo que você disponibiliza para os usuários. Aqui, o número de solicitações é ainda maior e a velocidade é tão vital. Mas como a natureza das solicitações é menos dinâmica, mecanismos adicionais de aprimoramento de desempenho podem ser aplicados, como armazenamento em cache de conteúdo ou balanceamento de carga.
OBSERVAÇÃO- Depois de configurar para otimização de desempenho, siga os procedimentos em Dia difícil para testar o ambiente sob carga pesada.
- Consulte também Dicas de ajuste de desempenho.
Metodologia de otimização de desempenho
Uma metodologia de otimização de desempenho para o AEM Projects pode ser resumida em cinco regras simples que podem ser seguidas para evitar problemas de desempenho desde o início:
Essas regras se aplicam aos projetos da Web em geral e são relevantes para os gerentes de projetos e administradores de sistema, a fim de garantir que seus projetos não enfrentem desafios de desempenho na hora do lançamento.
Planejamento para otimização
Planeje cerca de 10% do esforço do projeto para a fase de otimização de desempenho. Os requisitos reais de otimização de desempenho dependem do nível de complexidade de um projeto e da experiência da equipe de desenvolvimento. Embora seu projeto possa (em última análise) não exigir o tempo alocado, é uma boa prática planejar sempre a otimização de desempenho na região sugerida.
Sempre que possível, um projeto deve primeiro ser lançado de forma flexível para um público limitado para coletar experiência na vida real e executar outras otimizações, sem a pressão adicional que se segue a um anúncio completo.
Depois que você estiver "ao vivo", a otimização do desempenho não termina. Agora é quando você enfrenta a carga "real" em seu sistema. É importante planejar ajustes adicionais após o lançamento.
Como a carga do seu sistema muda e os perfis de desempenho do seu sistema mudam com o tempo, um "ajuste" ou "verificação de integridade" de desempenho deve ser programado em intervalos de 6 a 12 meses.
Simular Realidade
Se você acessar um site e descobrir, após o lançamento, que teve problemas de desempenho, é provável que seus testes de carga e desempenho não tenham simulado a realidade de maneira suficientemente precisa.
Simular a realidade é difícil e quanto esforço você quer investir para ficar "real" depende da natureza do seu projeto. "Real" significa não apenas "código real" e "tráfego real", mas também "conteúdo real", especialmente em relação ao tamanho e à estrutura do conteúdo. Seus modelos podem se comportar de forma diferente dependendo do tamanho e da estrutura do repositório.
Estabelecer metas sólidas
Não se deve subestimar a importância de estabelecer corretamente os objetivos de desempenho. Muitas vezes, depois que as pessoas se concentram em metas de desempenho específicas, é difícil alterar essas metas posteriormente, mesmo que elas se baseiem em suposições.
Estabelecer metas de desempenho boas e sólidas é realmente uma das áreas mais complicadas. Geralmente, é melhor coletar logs da vida real e benchmarks de um site comparável (por exemplo, o antecessor do novo site).
Permanecer relevante
É importante otimizar um gargalo de cada vez. Se você tentar fazer as coisas em paralelo sem validar o impacto de uma otimização, poderá perder o controle de qual medida de otimização ajudou.
Ciclos de iteração Agile
O ajuste de desempenho é um processo iterativo que envolve análise, otimização e validação até que a meta seja atingida. Para levar em conta esse aspecto, implemente um processo de validação ágil na fase de otimização em vez de um processo de teste mais pesado após cada iteração.
Esse foco significa que o desenvolvedor que implementa a otimização deve ter uma maneira rápida de saber se a otimização já atingiu a meta. Essas informações são importantes porque, quando a meta é atingida, a otimização é finalizada.
Diretrizes básicas de desempenho
De modo geral, mantenha suas solicitações de html não armazenadas em cache em menos de 100 milissegundos. Mais especificamente, podem servir de orientação os seguintes elementos:
- 70% das solicitações de páginas devem ser respondidas em menos de 100 milissegundos.
- 25% das solicitações de páginas devem receber uma resposta dentro de 100 milissegundos a 300 milissegundos.
- 4% das solicitações de páginas devem receber uma resposta dentro de 300 milissegundos a 500 milissegundos.
- 1% das solicitações para páginas deve receber uma resposta dentro de 500 milissegundos a 1000 milissegundos.
- Nenhuma página deve responder mais lentamente do que um segundo.
Os números acima assumem as seguintes condições:
- Medido na publicação (sem despesas gerais relacionadas a um ambiente de criação)
- Medido no servidor (sem sobrecarga de rede)
- Não armazenado em cache (sem cache de saída do AEM, sem cache do Dispatcher)
- Somente para itens complexos com muitas dependências (HTML, JS, PDF …)
- Nenhuma outra carga no sistema
Há alguns problemas que contribuem frequentemente para problemas de desempenho, incluindo os seguintes:
- Ineficiência de armazenamento em cache do Dispatcher
- O uso de queries em modelos de exibição normais.
O ajuste do nível de JVM e SO geralmente não resulta em saltos significativos no desempenho e, portanto, deve ser executado no final do ciclo de otimização.
A forma como um repositório de conteúdo é estruturado também pode afetar o desempenho. Para obter o melhor desempenho, o número de nós secundários anexados a nós individuais em um repositório de conteúdo não deve exceder 1.000 (como regra).
Seus melhores amigos durante um exercício normal de otimização de desempenho são:
- O
request.log - Tempo baseado em componentes
- Um profiler Java™.
Desempenho ao carregar e editar o Digital Assets
Devido ao grande volume de dados envolvidos ao carregar e editar ativos digitais, o desempenho pode se tornar um problema.
Dois itens afetam o desempenho aqui:
- CPU - vários núcleos permitem um trabalho mais suave durante a transcodificação
- Disco rígido - discos RAID paralelos alcançam o mesmo
Para melhorar o desempenho, considere o seguinte:
- Quantos ativos serão carregados por dia? Uma boa estimativa pode ser baseada em:
- O período em que as edições são feitas (normalmente a duração do dia de trabalho, mais para operações internacionais).
- O tamanho médio das imagens carregadas (e o tamanho das representações geradas por imagem) em megabytes.
- Determine a taxa média de dados:
- 80% de todas as edições são feitas em 20% das vezes, portanto, no horário de pico, você tem quatro vezes a taxa média de dados. Esse desempenho é o seu objetivo.
Monitoramento de desempenho
O desempenho (ou a falta dele) é uma das primeiras coisas que os usuários notam, de modo que com qualquer aplicativo com interface do usuário, o desempenho é de importância fundamental. Para otimizar o desempenho da instalação do AEM, monitore vários atributos da instância e seu comportamento.
Para obter informações sobre como executar o monitoramento do desempenho, consulte Monitoramento do Desempenho.
Os problemas que causam problemas de desempenho geralmente são difíceis de rastrear, mesmo quando seus efeitos são fáceis de ver.
Um ponto de partida básico é um bom conhecimento do seu sistema quando ele está funcionando normalmente. A menos que você saiba a aparência e o comportamento do seu ambiente quando ele funciona corretamente, é difícil localizar o problema quando o desempenho piora. Gaste tempo investigando o sistema quando ele estiver funcionando sem problemas e garanta que a coleta de informações de desempenho seja uma tarefa contínua. Isso fornece uma base de comparação caso o desempenho sofra.
O diagrama a seguir ilustra o caminho que uma solicitação de conteúdo do AEM pode tomar e, portanto, o número de diferentes elementos que podem afetar o desempenho.
O desempenho também é um equilíbrio entre volume e capacidade:
- Volume - A quantidade de saída processada e entregue pelo sistema.
- Capacidade - A capacidade do sistema de entregar o volume.
O desempenho pode ser ilustrado em vários locais na cadeia da Web.
Há várias áreas funcionais que geralmente são responsáveis por afetar o desempenho:
- Armazenamento em cache
- Código do aplicativo (seu projeto)
- Funcionalidade de pesquisa
Regras Básicas De Desempenho
Algumas regras devem ser levadas em conta ao otimizar o desempenho:
- O ajuste de desempenho deve fazer parte de todos os projetos.
- Não otimize no início do ciclo de desenvolvimento.
- O desempenho só é tão bom quanto o link mais fraco.
- Sempre pense em capacidade ou volume.
- Otimize coisas importantes primeiro.
- Nunca otimizar sem metas realistas.
OBSERVAÇÃOConfiguração do para desempenho
Determinados aspectos do AEM (e/ou do repositório subjacente) podem ser configurados para otimizar o desempenho. Veja a seguir possibilidades e sugestões. Certifique-se de usar a funcionalidade em questão ou de como usá-la antes de fazer alterações.
OBSERVAÇÃOIndexação de pesquisa
A partir do AEM 6.0, o Adobe Experience Manager usa uma arquitetura de repositório baseada em Oak.
Você pode encontrar as informações de indexação atualizadas aqui:
Processamento de fluxo de trabalho simultâneo
Para melhorar o desempenho, limite o número de processos de workflow em execução simultânea. Por padrão, o motor de workflow processa tantos workflows em paralelo quanto há processadores disponíveis para a Java™ VM. Quando as etapas do fluxo de trabalho exigem grandes quantidades de recursos de processamento (RAM ou CPU), executar vários desses fluxos de trabalho em paralelo pode colocar grandes demandas nos recursos disponíveis do servidor.
Por exemplo, quando imagens (ou ativos DAM em geral) são carregadas, os fluxos de trabalho importam automaticamente as imagens para o DAM. As imagens geralmente têm alta resolução e podem consumir facilmente centenas de MB de heap para processamento. O manuseio dessas imagens em paralelo coloca uma alta carga no subsistema de memória e no coletor de lixo.
O mecanismo de fluxo de trabalho usa as filas de trabalho do Apache Sling para manipular e agendar o processamento do item de trabalho. Os seguintes serviços de fila de trabalhos foram criados por padrão na fábrica do serviço de configuração da fila de trabalhos do Apache Sling para processar trabalhos de fluxo de trabalho:
- Fila de fluxo de trabalho do Granite: a maioria das etapas do fluxo de trabalho, como aquelas que processam ativos DAM, usam o serviço Fila de fluxo de trabalho do Granite.
- Fila de trabalho do processo externo do fluxo de trabalho do Granite: esse serviço é usado para etapas especiais do fluxo de trabalho externo que normalmente são usadas para entrar em contato com um sistema externo e pesquisar resultados. Por exemplo, a etapa Processo de extração de mídia do InDesign é implementada como um processo externo. O mecanismo de workflow usa a fila externa para processar a pesquisa. (Consulte com.day.cq.workflow.exec.WorkflowExternalProcess.)
Configure esses serviços para limitar o número máximo de processos de fluxo de trabalho simultâneos.
OBSERVAÇÃOConfiguração no repositório
Se você estiver configurando os serviços usando um nó sling:OsgiConfig, localize o PID dos serviços existentes, por exemplo: org.apache.sling.event.jobs.QueueConfiguration.370aad73-d01b-4a0b-abe4-20198d85f705. Você pode descobrir o PID usando o Console da Web.
Configure a propriedade chamada queue.maxparallel.
Configuração no console da Web
Para configurar esses serviços usando o Console da Web, localize os itens de configuração existentes abaixo da fábrica do serviço de Configuração da Fila de Trabalhos do Apache Sling.
Configure a propriedade chamada Máximo de Trabalhos Paralelos.
Configurar a Fila para um Fluxo de Trabalho Específico
Crie uma fila de trabalhos para um modelo de fluxo de trabalho específico para poder configurar o manuseio de trabalhos para esse modelo de fluxo de trabalho. Dessa forma, suas configurações afetam o processamento de um workflow específico, enquanto a configuração da Fila de workflow padrão do Granite controla o processamento de outros workflows.
Quando os modelos de fluxo de trabalho são executados, eles criam trabalhos do Sling para um tópico específico. Por padrão, o tópico corresponde aos tópicos configurados para a Fila geral de fluxos de trabalho do Granite ou a Fila de trabalho do processo externo do Granite:
com/adobe/granite/workflow/job*com/adobe/granite/workflow/external/job*
Os tópicos de trabalho reais que os modelos de fluxo de trabalho geram incluem o sufixo específico do modelo. Por exemplo, o modelo de fluxo de trabalho Ativo de atualização do DAM gera trabalhos com o seguinte tópico:
com/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/model
Portanto, você pode criar uma fila de trabalhos para o tópico que corresponda aos tópicos de trabalho do seu modelo de fluxo de trabalho. A configuração das propriedades relacionadas ao desempenho da fila afeta somente o modelo de fluxo de trabalho que gera as tarefas que correspondem ao tópico da fila.
O procedimento a seguir cria uma fila de trabalhos para um fluxo de trabalho, usando o fluxo de trabalho Ativo de atualização do DAM como exemplo.
-
Execute o modelo de fluxo de trabalho para o qual deseja criar a fila de trabalhos, para que as estatísticas de tópico sejam geradas. Por exemplo, adicione uma imagem ao Assets para executar o fluxo de trabalho Ativo de atualização do DAM.
-
Abra o console Sling Jobs (
https://<host>:<port>/system/console/slingevent). -
Descubra os tópicos relacionados ao fluxo de trabalho no console. Para Ativo de atualização do DAM, os seguintes tópicos são encontrados:
com/adobe/granite/workflow/external/job/etc/workflow/models/dam/update_asset/jcr_content/modelcom/adobe/granite/workflow/job/etc/workflow/models/dam/update_asset/jcr_content/modelcom/adobe/granite/workflow/job/etc/workflow/models/dam-xmp-writeback/jcr_content/model
-
Crie uma fila de tarefas para cada um desses tópicos. Para criar uma fila de trabalhos, crie uma configuração de fábrica para o serviço de fábrica da Fila de trabalhos do Apache Sling.
As configurações de fábrica são semelhantes à Fila de Fluxo de Trabalho do Granite descrita em Processamento de Fluxo de Trabalho Simultâneo, exceto que a propriedade Topics corresponde ao tópico dos seus trabalhos de fluxo de trabalho.
Serviço de sincronização de ativos DAM do AEM
O AssetSynchronizationService é usado para sincronizar ativos de repositórios montados (incluindo LiveLink, Documentum®, entre outros). Por padrão, essa sincronização faz uma verificação regular a cada 300 segundos (5 minutos); portanto, se você não usar repositórios montados, poderá desativar esse serviço.
A desabilitação do serviço é feita por configuração do serviço OSGi Serviço de Sincronização de Ativos DAM CQ para definir o Período de sincronização ( scheduler.period) para (no mínimo) um ano (definido em segundos).
Várias instâncias do DAM
A implantação de várias instâncias do DAM pode ajudar no desempenho quando, por exemplo:
- Você tem uma alta carga devido ao carregamento regular de muitos ativos para o ambiente de criação; aqui, uma instância do DAM separada pode ser dedicada ao autor de serviço.
- Você tem várias equipes em locais mundiais (por exemplo, EUA, Europa, Ásia).
Outras considerações são:
- Separação de "trabalho em andamento" no autor de "final" na publicação
- Separação de usuários internos na criação dos visitantes/usuários externos na publicação (por exemplo, agentes, representantes da imprensa, clientes e estudantes).
Práticas recomendadas para o Quality Assurance
O desempenho é de suma importância para o ambiente de publicação. Portanto, você deve planejar e analisar cuidadosamente os testes de desempenho feitos para o ambiente de publicação ao implementar seu projeto.
Esta seção tem como objetivo fornecer uma visão geral padronizada dos problemas envolvidos na definição de um conceito de teste especificamente para testes de desempenho no seu ambiente publicar. Essas informações são de interesse principalmente para engenheiros de controle de qualidade, gerentes de projeto e administradores de sistema.
O documento a seguir aborda uma abordagem padronizada para testes de desempenho para um aplicativo do AEM no ambiente Publicar. Este teste de desempenho envolve as cinco fases a seguir:
O controle é um processo extra abrangente - necessário, mas não limitado a testes.
Verificação do conhecimento
Uma primeira etapa é documentar as informações básicas que você deve saber antes de iniciar o teste:
- A arquitetura de seu ambiente de teste
- Um mapa de aplicativos detalhando os elementos internos que precisam de teste (isoladamente e em combinação)
Arquitetura de teste
Documente a arquitetura do ambiente de teste que está sendo usado para seu teste de desempenho.
Você precisa de uma reprodução do ambiente de publicação de produção planejado, juntamente com o Dispatcher e o Balanceador de carga.
Mapa de aplicativos
Obtenha uma visão geral clara a partir da qual é possível criar um mapa do aplicativo inteiro (talvez você já tenha esse mapa a partir de testes no ambiente do Autor).
Uma representação de diagrama dos elementos internos do aplicativo pode fornecer uma visão geral dos requisitos de teste; com a codificação por cores, também pode servir como base para os relatórios.
Definição do escopo
Um aplicativo geralmente tem uma seleção de casos de uso. Alguns casos de uso são importantes, outros menos.
Para focalizar o escopo do teste de desempenho na publicação, a Adobe recomenda que você defina o seguinte:
- Casos de uso de negócios mais importantes
- Casos de uso técnico mais críticos
O número de casos de uso depende de você, mas deve ser limitado a um número facilmente gerenciável (por exemplo, entre 5 e 10).
Depois que os casos de uso principais forem selecionados, os KPIs (indicadores-chave de desempenho) e as ferramentas usadas para medi-los poderão ser definidos para cada caso. Exemplos de KPIs comuns incluem:
- Tempo de resposta de ponta a ponta
- Tempo de resposta do servlet
- Tempo de resposta para um único componente
- Tempo de resposta dos serviços
- Número de threads ociosos no pool de threads
- Número de conexões livres
- Recursos do sistema, como CPU e acesso de E/S
Metodologias de teste
Este conceito tem quatro cenários usados para definir e testar as metas de desempenho:
- Testes de componente único
- Testes de componente combinado
- Cenário de ativação
- Cenários de erro
Com base nos seguintes princípios:
Pontos de interrupção do componente
- Cada componente tem um ponto de interrupção específico quando relacionado ao desempenho. Ou seja, um componente pode mostrar um bom desempenho até que um ponto específico seja atingido, após o qual o desempenho é degradado rapidamente.
- Para obter uma visão geral completa do aplicativo, primeiro verifique seus componentes para determinar quando o ponto de interrupção de cada um é atingido.
- Para descobrir o ponto de interrupção em que é possível executar um teste de carga, no qual, ao longo de um período, é possível aumentar o número de usuários para criar uma carga crescente. Ao monitorar essa carga e a resposta dos componentes, você encontra um comportamento de desempenho específico quando o ponto de interrupção do componente é atingido. O ponto pode ser qualificado pelo número de transações simultâneas por segundo, juntamente com o número de usuários simultâneos (se o componente for sensível a esse KPI).
- Essas informações podem servir como referência para melhorias, indicar a eficiência das medidas usadas e ajudar a definir cenários de teste.
