Depois que suas instâncias AEM tiverem sido implantadas, determinadas tarefas serão necessárias para monitorar e manter sua operação, desempenho e integridade.
Um fator chave aqui é que para reconhecer possíveis problemas você precisa saber como seus sistemas se parecem e se comportam em condições normais. A melhor forma de o fazer é monitorar o sistema e coletar informações ao longo de um período de tempo.
Marcar | Considerações | Comentário / Ações |
---|---|---|
Plano de backup. | Consulte como Fazer backup da sua instância. | |
Plano de recuperação de desastres. | Suas diretrizes de recuperação de desastres para empresas. | |
Um sistema de rastreamento de erros está disponível para problemas de relatórios. | Por exemplo, bugzilla, jira ou um de muitos outros. | |
Os sistemas de arquivos estão sendo monitorados. | O repositório CRX "congela" se não houver espaço livre em disco suficiente. Ele será retomado assim que o espaço se tornar disponível. | As mensagens " *ERROR* LowDiskSpaceBlocker " podem ser vistas no arquivo de log quando o espaço livre se tornar baixo. |
Os arquivos de log estão sendo monitorados. | ||
O monitoramento do sistema está (constantemente) sendo executado em segundo plano. | Incluindo o uso da CPU, memória, disco e rede. Usando, por exemplo, iostat / vmstat / perfmon. | Os dados registrados são visualizados e podem ser usados para rastrear problemas de desempenho. Os dados brutos também podem ser acessados. |
AEM desempenho está sendo monitorado. | Incluindo Solicitar contadores para monitorar os níveis de tráfego. | Caso se verifique uma perda significativa ou a longo prazo do desempenho, deve ser efetuada uma investigação aprofundada. |
Você está monitorando seus Agentes de Replicação. | ||
Expurgar instâncias de fluxo de trabalho regularmente. | Tamanho do repositório e desempenho do fluxo de trabalho. | Consulte Expurgação Regular de Instâncias de Fluxo de Trabalho. |
É uma boa prática fazer backups de:
Sua empresa provavelmente terá uma política de backup que será necessário seguir, considerações adicionais sobre o que fazer backup e quando incluir:
Muitas vezes, é feito um backup completo em intervalos regulares (por exemplo, diários, semanais ou mensais), com backups incrementais entre (por exemplo, por hora, por dia ou por semana).
Ao implementar backups de suas instâncias de produção, testes devem ser feitos para garantir que o backup possa ser restaurado com êxito.
Sem isso, o backup é potencialmente inútil (pior cenário).
Para obter mais informações sobre o desempenho do backup, leia a seção Desempenho do Backup.
Após a instalação, ou alterações significativas na configuração, faça um backup da instalação do software.
Para fazer isso, é necessário fazer backup de todo o repositório e:
<cq-installation-dir>
do seu sistema de arquivos.Se você estiver operando um servidor de aplicativos de terceiros, as pastas adicionais podem estar em um local diferente e talvez também seja necessário fazer backup delas. Consulte Como instalar AEM com um Servidor de Aplicativos para obter informações sobre como instalar servidores de aplicativos.
Há suporte para backup incremental do armazenamento de dados de arquivos; ao usar backup incremental para outros componentes (como o índice Lucene), verifique se os arquivos excluídos também estão marcados como excluídos no backup.
O espelhamento de disco também pode ser usado como um mecanismo de backup.
A seção Backup e restauração da documentação CRX abrange todos os problemas relacionados aos backups do repositório CRX.
Para obter todos os detalhes sobre como fazer um backup "ativo" on-line, consulte Criando um Backup On-line.
A ferramenta Expurgar Versões destina-se a expurgar as versões de um nó ou uma hierarquia de nós no repositório. Seu objetivo principal é ajudar a reduzir o tamanho do repositório, removendo versões antigas de seus nós.
Esta seção trata das operações de manutenção relacionadas ao recurso de controle de versão do AEM. A ferramenta Limpar versão destina-se a expurgar as versões de um nó ou hierarquia de nós no repositório. Seu objetivo principal é ajudar a reduzir o tamanho do repositório, removendo versões antigas de seus nós.
A ferramenta Expurgar Versões está disponível no console Ferramentas em Versionamento ou diretamente em:
https://<server>:<port>/etc/versioning/purge.html
Caminho do startUm caminho absoluto no qual a expurgação deve ser feita. Você pode selecionar o Caminho do Start clicando no navegador da árvore do repositório.
RecursivoAo expurgar dados, você pode escolher entre executar a operação em um nó ou em uma hierarquia inteira selecionando Recursivo. No último caso, o caminho especificado define o nó raiz da hierarquia.
Máximo de versões para manterO número máximo de versões a serem mantidas para um nó. Quando esse número excede esse valor, as versões mais antigas são removidas.
Idade máxima da versãoA idade máxima da versão de um nó. Quando a idade de uma versão exceder esse valor, ele será removido.
Execução secaComo a remoção de versões do conteúdo é definitiva e não pode ser revertida sem a restauração de um backup, a ferramenta Expurgar versões fornece um modo de execução em seco que permite a pré-visualização das versões expurgadas. Para iniciar uma execução seca do processo de expurgação, clique em Execução de prática.
LimparInicie a expurgação das versões no nó definido pelo Caminho do Start.
Para expurgar versões de um site, proceda da seguinte maneira:
Navegue até o console Ferramentas, selecione Controle de versão e clique com o duplo em Limpar versões.
Defina o caminho do start do conteúdo a ser expurgado (por exemplo, /content/geometrixx-outdoors
).
Defina o número máximo de versões (para cada nó) que deseja manter. Deixe em branco para não usar essa configuração.
Defina a idade máxima da versão em dias (para cada nó) que deseja manter. Deixe em branco para não usar essa configuração.
Clique em Execução de prática para pré-visualização do que o processo de expurgação faria.
Clique em Limpar para iniciar o processo.
Os nós removidos não podem ser revertidos sem restaurar o repositório. Você deve cuidar de sua configuração, então recomendamos que você sempre execute uma execução seca antes de purgar.
As Execução de prática e Limpar processam a lista de todos os nós que foram processados. Durante o processo, um nó pode ter um dos seguintes status:
ignore (not versionnable)
: o nó não oferece suporte ao controle de versão e é ignorado durante o processo.ignore (no version)
: o nó não tem nenhuma versão e é ignorado durante o processo.retained
: o nó não é expurgado.purged
: o nó é limpo.Além disso, o console fornece informações úteis sobre as versões:
V 1.0
: o número da versão.V 1.0.1
&Último;: a estrela indica que a versão é a atual.Thu Mar 15 2012 08:37:32 GMT+0100
: a data da versão.No próximo exemplo:
Registros de auditoria e arquivos de registro relacionados ao Adobe Experience Manager (AEM) podem ser encontrados em vários locais. A seguir, é fornecida uma visão geral do que você pode encontrar.
AEM WCM registra registros detalhados. Depois de desempacotar e start Quickstart, você pode encontrar registros em:
<cq-installation-dir>/crx-quickstart/logs/
<cq-installation-dir>/crx-quickstart/repository/
A rotação do arquivo de log refere-se ao processo que limita o crescimento do arquivo ao criar um novo arquivo periodicamente. No AEM, um arquivo de log chamado error.log
será girado uma vez por dia, de acordo com as regras fornecidas:
error.log
é renomeado de acordo com o padrão {original_filename} .yyyy-MM-dd
. Por exemplo, em 11 de julho de 2010, o arquivo de log atual é renomeado como error.log-2010-07-10
e um novo error.og
é criado.Se você atualizar sua instalação AEM, observe que qualquer arquivo de log existente que não for mais usado pelo AEM permanecerá no disco. Você pode removê-los sem riscos. Todas as novas entradas de log serão gravadas nos novos arquivos de log.
Vários arquivos de log são mantidos no servidor de arquivos onde você instalou AEM:
<cq-installation-dir>/crx-quickstart/logs
access.log
Todas as solicitações de acesso ao AEM WCM e ao repositório são registradas aqui.
audit.log
As ações de moderação estão registradas aqui.
error.log
Mensagens de erro (de níveis variados de gravidade) são registradas aqui.
ImageServer-<PortId>-yyyy>-<mm>-<dd>.log
Esse log só será usado se a mídia dinâmica estiver ativada. Fornece estatísticas e informações analíticas usadas para analisar o comportamento do processo interno do ImageServer.
request.log
Cada solicitação de acesso é registrada aqui junto com a resposta.
Esse log só será usado se a mídia dinâmica estiver ativada. O registro s7access registra cada solicitação feita à Dynamic Media por meio de /is/image
e /is/content
.
stderr.log
Retém mensagens de erro, novamente de níveis variáveis de gravidade, geradas durante a inicialização. Por padrão, o nível de log está definido como Warning
( WARN
)
stdout.log
Retém mensagens de registro indicando eventos durante a inicialização.
upgrade.log
Fornece um log de todas as operações de atualização que são executadas nos pacotes com.day.compat.codeupgrade
e com.adobe.cq.upgradesexecutor
.
<cq-installation-dir>/crx-quickstart/repository
revision.log
Revise as informações do diário.
Os registros ImageServer e s7access não estão incluídos no pacote Download Full gerado a partir da página system/console/status-Bundlelist. Para fins de suporte, se você tiver problemas com a Dynamic Media, anexe também os registros do ImageServer e s7access ao entrar em contato com o Suporte ao cliente.
O nível de log padrão Apache Sling Logging Configuration é Information, portanto, as mensagens de depuração não são registradas em log.
Para ativar o nível de log de depuração para um Logger, defina a propriedade org.apache.sling.commons.log.level
para depurar no repositório. Por exemplo, em /libs/sling/config/org.apache.sling.commons.log.LogManager
para configurar o registro Apache Sling global.
Não deixe o log no nível do log de depuração por mais tempo do que o necessário, pois ele gera muitas entradas de log, consumindo recursos.
Uma linha no arquivo de depuração geralmente é start com DEBUG, em seguida, fornece o nível de log, a ação do instalador e a mensagem de log. Por exemplo:
DEBUG 3 WebApp Panel: WebApp successfully deployed
Os níveis de log são os seguintes:
0 | Erro fatal | A ação falhou e o instalador não pode continuar. |
---|---|---|
1 | Erro | A ação falhou. A instalação continua, mas uma parte do AEM WCM não foi instalada corretamente e não funcionará. |
2 | Aviso | A ação foi bem-sucedida, mas encontrou problemas. AEM WCM pode ou não funcionar corretamente. |
3 | Info | A ação foi bem sucedida. |
Ao trabalhar com a Adobe Experience Manager, existem vários métodos de gestão das definições de configuração para esses serviços; consulte Configuração do OSGi para obter mais detalhes e as práticas recomendadas.
Em determinadas circunstâncias, você pode querer criar um arquivo de log personalizado com um nível de log diferente. Você pode fazer isso no repositório:
Se ainda não existir, crie uma nova pasta de configuração ( sling:Folder
) para seu projeto /apps/<project-name>/config
.
Em /apps/<project-name>/config
, crie um nó para a nova Configuração do Apache Sling Logging Logger:
org.apache.sling.commons.log.LogManager.factory.config-<identifier>
(como este é um Logger)
Em que <identifier>
é substituído pelo texto livre que você (deve) deve digitar para identificar a instância (não é possível omitir essas informações). Por exemplo, org.apache.sling.commons.log.LogManager.factory.config-MINE
sling:OsgiConfig
Embora não seja um requisito técnico, é aconselhável tornar <identifier>
único.
Defina as seguintes propriedades neste nó:
Nome: org.apache.sling.commons.log.file
Tipo: String
Valor: especificar o arquivo de log; por exemplo, logs/myLogFile.log
Nome: org.apache.sling.commons.log.names
Tipo: String[] (String + Multi)
Valor: especificar os serviços OSGi para os quais o agente de registro deve registrar as mensagens; por exemplo, todas as seguintes opções:
org.apache.sling
org.apache.felix
com.day
Nome: org.apache.sling.commons.log.level
Tipo: String
Valor: especifique o nível de log necessário ( debug
, info
, warn
ou error
); por exemplo debug
Configure os outros parâmetros conforme necessário:
Nome: org.apache.sling.commons.log.pattern
Tipo: String
Valor: especificar o padrão da mensagem de registro, conforme necessário; por exemplo,
{0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
org.apache.sling.commons.log.pattern
apoia até seis argumentos.
{0} O carimbo de data e hora do tipo java.util.Date
{1} o marcador de log
{2} o nome do thread atual
{3} o nome do agente de log
{4} o nível de log
{5} a mensagem de registro
Se a chamada de log incluir um Throwable
, o rastreamento de pilha será anexado à mensagem.
org.apache.sling.commons.log.names deve ter um valor.
Os caminhos do gravador de log são relativos ao local crx-quickstart
.
Portanto, um arquivo de log especificado como:
logs/thelog.log
escreve para:
<cq-installation-dir>/crx-quickstart/logs/thelog.log
.
E um arquivo de log especificado como:
../logs/thelog.log
grava em um diretório:
<cq-installation-dir>/logs/
(isto é, próximo a <cq-installation-dir>/crx-quickstart/
)
Essa etapa só é necessária quando um novo Gravador é necessário (isto é, com uma configuração diferente do Gravador padrão).
Uma nova Configuração de Gravador de Log é necessária somente quando o padrão existente não é adequado.
Se nenhum Escritor explícito estiver configurado, o sistema gerará automaticamente um Escritor implícito com base no padrão.
Em /apps/<project-name>/config
, crie um nó para a nova Configuração do Apache Sling Logging Writer:
Nome: org.apache.sling.commons.log.LogManager.factory.writer-<identifier>
(como este é um Escritor)
Assim como no Logger, <identifier>
é substituído pelo texto livre que você (deve) deve digitar para identificar a instância (não é possível omitir essas informações). Por exemplo, org.apache.sling.commons.log.LogManager.factory.writer-MINE
Tipo: sling:OsgiConfig
Embora não seja um requisito técnico, é aconselhável tornar <identifier>
único.
Defina as seguintes propriedades neste nó:
Nome: org.apache.sling.commons.log.file
Tipo: String
Valor: especificar o arquivo de log para que ele corresponda ao arquivo especificado no Log;
neste exemplo, ../logs/myLogFile.log
.
Configure os outros parâmetros conforme necessário:
Nome: org.apache.sling.commons.log.file.number
Tipo: Long
Valor: especifique o número de arquivos de log que deseja manter; por exemplo, 5
Nome: org.apache.sling.commons.log.file.size
Tipo: String
Valor: especificar, se for caso disso, o controlo da rotação dos ficheiros por dimensão/data; por exemplo, '.'yyyy-MM-dd
org.apache.sling.commons.log.file.size
controla a rotação do arquivo de log ao configurar:
para indicar quando um novo arquivo será criado (e o arquivo existente será renomeado de acordo com o padrão de nome).
KB
, MB
ou GB
(caso seja ignorado).java.util.SimpleDateFormat
. Isso define o período após o qual o arquivo será girado; também o sufixo anexado ao arquivo girado (para identificação).O padrão é '.'aaaa-MM-dd (para rotação diária do log).
Assim, por exemplo, à meia-noite de 20 de janeiro de 2010 (ou quando a primeira mensagem de registro depois disso ocorrer para ser precisa), …/logs/error.log será renomeado para …/logs/error.log.2010-01-20. O registro para o dia 21 de janeiro será enviado para (um novo e vazio) …/logs/error.log até que seja lançado na próxima mudança de dia.
'.'yyyy-MM |
Rotação no início de cada mês |
---|---|
'.'yyyy-ww |
Rotação no primeiro dia de cada semana (depende da localidade). |
'.'yyyy-MM-dd |
Rotação à meia-noite todos os dias. |
'.'yyyy-MM-dd-a |
Rotação à meia-noite e ao meio-dia de cada dia. |
'.'yyyy-MM-dd-HH |
Rotação no topo de cada hora. |
'.'yyyy-MM-dd-HH-mm |
Rotação no início de cada minuto. |
Observação: Ao especificar uma data/hora:
isso serve para evitar que determinados caracteres sejam interpretados como letras padrão.
Leia seu novo arquivo de log com a ferramenta escolhida.
O arquivo de log criado por este exemplo será ../crx-quickstart/logs/myLogFile.log
.
O Console do Felix também fornece informações sobre o suporte ao Sling Log em ../system/console/slinglog
; por exemplo http://localhost:4502/system/console/slinglog
.
Os registros de auditoria são mantidos para fornecer um registro de quem fez o quê e quando. Registros de auditoria diferentes são gerados para eventos AEM WCM e OSGi.
Abra uma página.
No sidekick, você pode selecionar a guia com o ícone de cadeado e clicar com o duplo em Log de auditoria…
Uma nova janela será aberta mostrando a lista dos registros de auditoria para a página atual.
Clique em OK quando quiser fechar a janela.
Na pasta /var/audit
, os registros de auditoria são mantidos de acordo com o recurso. Você pode fazer o detalhamento até visualizar os registros individuais e as informações que eles contêm.
Essas entradas possuem as mesmas informações que são exibidas ao editar uma página.
Os eventos OSGi também geram registros de auditoria que podem ser vistos na guia Status de Configuração -> Arquivos de Log no Console da Web AEM:
Você pode monitorar suas filas de replicação para detectar quando uma fila está desativada ou bloqueada - o que, por sua vez, pode indicar um problema com uma instância de publicação ou sistema externo:
todas as filas necessárias estão ativadas?
alguma fila desativada ainda é necessária?
todas as filas enabled
devem ter o status idle
ou active
, que indicam a operação normal; nenhuma filas deve ser blocked
, o que geralmente é um sinal de problemas no lado dos receptores.
se o tamanho da fila aumentar com o tempo, isso pode indicar uma fila bloqueada.
Para monitorar um agente de replicação:
Acesse a guia Ferramentas no AEM.
Clique em Replicação.
Clique com o duplo no link para os agentes do ambiente apropriado (no painel esquerdo ou direito); por exemplo, Agentes no autor.
A janela resultante mostra uma visão geral de todos os seus agentes de replicação para o ambiente do autor, incluindo seu público alvo e status.
Clique no nome do agente apropriado (que é um link) para mostrar informações detalhadas sobre esse agente:
Aqui você pode:
Não use o link "Testar conexão" para a caixa de saída de replicação inversa em uma instância de publicação.
Se um teste de replicação for executado para uma fila de caixa de saída, todos os itens mais antigos que a replicação de teste serão processados novamente com cada replicação reversa.
Se esses itens já existirem em uma fila, eles podem ser encontrados com o seguinte query XPath JCR e devem ser removidos.
/jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']
Novamente, você pode desenvolver uma solução para detectar todos os agentes de replicação (localizados em /etc/replication/author
ou /etc/replication/publish
), em seguida, verificar o status do agente ( enabled
, disabled
) e a fila subjacente ( active
, idle
, blocked
).
A Otimização de desempenho é um processo interativo que recebe foco durante o desenvolvimento. Depois da implantação, geralmente é revisado após eventos ou intervalos específicos.
Os métodos usados ao coletar informações para otimização também podem ser usados para monitoramento contínuo.
Configurações específicas disponíveis para melhorar o desempenho também podem ser verificadas.
As listas a seguir apresentam problemas comuns de desempenho, juntamente com propostas sobre como detectar e contrariá-los.
Área | Sintoma(s) | Para aumentar a capacidade… | Para reduzir o volume… |
---|---|---|---|
Cliente | Alto uso da CPU do cliente. | Instale uma CPU cliente com desempenho mais alto. | Simplificar o layout (HTML). |
Baixo uso da CPU do servidor. | Atualize para um navegador mais rápido. | Melhore o cache do cliente. | |
Alguns clientes são rápidos, alguns lentos. | |||
Servidor | |||
Rede | O uso da CPU é baixo nos servidores e clientes. | Remova todos os gargalos de rede. | Melhore/otimize a configuração do cache do cliente. |
A navegação local no servidor é (comparativamente) rápida. | Aumente a largura de banda da rede. | Reduza o "peso" de suas páginas da Web (por exemplo, menos imagens, HTML otimizado). | |
Servidor Web | O uso da CPU no servidor da Web é alto. | Agrupe seus servidores da Web. | Reduza as ocorrências por página (visita). |
Use um balanceador de carga de hardware. | |||
Aplicativo | O uso da CPU do servidor é alto. | Agrupe suas instâncias AEM. | Procure e elimine pernos de CPU e memória (use análise de código, saída de tempo etc). |
Alto consumo de memória. | Melhore o cache em todos os níveis. | ||
Baixo tempo de resposta. | Otimizar modelos e componentes (por exemplo, estrutura, lógica). | ||
Repositório | |||
Cache |
Problemas de desempenho podem resultar de várias causas que não têm nada a ver com seu site, incluindo lentidão temporária na velocidade da conexão, carga da CPU e muito mais.
Isso também pode afetar todos os seus visitantes, ou somente um subconjunto deles.
Todas essas informações precisam ser obtidas, selecionadas e analisadas antes que você possa otimizar o desempenho geral ou resolver problemas específicos.
Antes de enfrentar um problema de desempenho:
Ao enfrentar um problema de desempenho:
tente replicá-lo com um (ou, de preferência, mais) navegador da Web padrão, em um cliente diferente que você sabe que tem bom desempenho geral e/ou no próprio servidor (se possível)
verifique se algo (relacionado ao sistema) mudou em um espaço de tempo apropriado e se alguma dessas alterações pode ter afetado o desempenho
faça perguntas como:
coletar o máximo de informações possível para comparar com seu conhecimento do sistema em circunstâncias normais:
A seguir, há uma breve visão geral de algumas das ferramentas disponíveis para monitorar e analisar o desempenho.
Alguns deles dependerão do seu sistema operacional.
Ferramenta | Usado para analisar... | Uso / Mais informações... |
request.log | Tempo de resposta e simultaneidade. | Interpretação do request.log. |
trusco/traço | Carregamentos de página | Comandos Unix/Linux para rastrear chamadas e sinais do sistema. Aumente o nível de log para Analise o número de cargas de página por solicitação, quais páginas etc. |
Despejo de thread | Observe threads JVM. Identifique as disputas, bloqueios e corredores longos. | Dependendo do sistema operacional: Ferramentas de análise também estão disponíveis, como TDA. |
Despejos de heap | Problemas de falta de memória que causam desempenho lento. | Adicione a opção: Consulte o Guia de solução de problemas do Java SE 6 com a VM HotSpot. |
Chamadas do sistema | Identifique problemas de tempo. | As chamadas para Nota: Devem ser implementados para que possam ser ativados/desativados conforme necessário; quando um sistema estiver a funcionar sem problemas, a sobrecarga da recolha de estatísticas não será necessária. |
Apache Bench | Identifique os vazamentos de memória, analise seletivamente o tempo de resposta. | o uso básico é:
Consulte Apache Bench e ab man page para obter detalhes completos. |
Análise de pesquisa | Execute query de pesquisa offline, identifique o tempo de resposta do query, teste e confirme o conjunto de resultados. |
|
JMeter | Ensaios de carga e de funcionamento. | https://jakarta.apache.org/jmeter/ |
JProfiler | Definição de perfil detalhada da CPU e da memória. | https://www.ej-technologies.com/ |
JConsole | Observe métricas e threads JVM. | Uso: jconsole Consulte jconsole e Monitorando o desempenho usando JConsole. Observação: com o JDK 1.6, o JConsole é extensível com plug-ins; por exemplo, Superior ou TDA (Thread Dump Analyzer). |
Java VisualVM | Observe métricas, threads, memória e criação de perfis JVM. | Uso: jvisualvm ou visual Consulte jvisualvm, visualvm e Monitorando o desempenho usando (J)VisualVM. Observação: com o JDK 1.6, o VisualVM é extensível com plug-ins. |
trusco/traço, lista | Chamada de kernel e análise de processo (Unix). | Comandos Unix/Linux. |
Estatísticas de tempo | Consulte estatísticas de tempo para renderização de página. | Para ver as estatísticas de tempo para renderização de página, você pode usar Ctrl-Shift-U junto com |
Ferramenta de definição de perfis de CPU e memória |
Usado ao analisar solicitações lentas durante o desenvolvimento. | Por exemplo, YourKit. |
Coleta de informações | O estado contínuo da sua instalação. | Saber o máximo possível sobre a sua instalação também pode ajudá-lo a rastrear o que pode ter causado uma mudança no desempenho e se essas alterações são justificadas. Essas métricas precisam ser coletadas em intervalos regulares para que você possa ver facilmente alterações significativas. |
Este arquivo registra informações básicas sobre cada solicitação feita para AEM. A partir destas valiosas conclusões pode ser extraída.
O request.log
oferta uma maneira integrada para obter uma visão de quanto tempo as solicitações demoram. Para fins de desenvolvimento, é útil tail -f
o request.log
e observar os tempos de resposta lentos. Para analisar um request.log
maior, recomendamos o uso de rlog.jar
que permite classificar e filtrar por tempos de resposta.
Recomendamos isolar as páginas "lentas" do request.log
e, em seguida, ajustá-las individualmente para obter um melhor desempenho. Isso geralmente é feito incluindo métricas de desempenho por componente ou usando uma ferramenta de definição de perfil de desempenho, como [yourkit](https://www.yourkit.com/)
.
O registro de solicitações registra cada solicitação feita, juntamente com a resposta feita:
09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms
Ao totalizar todas as entradas de GET dentro de um período específico (por exemplo, durante vários períodos de 24 horas), você pode fazer declarações sobre o tráfego médio em seu site.
Um bom ponto de partida para a análise de desempenho é o registro de solicitações:
<cq-installation-dir>/crx-quickstart/logs/request.log
O log é exibido da seguinte maneira (as linhas são encurtadas para simplificar):
31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms
Este registro tem uma linha por solicitação ou resposta:
A data em que cada solicitação ou resposta foi feita.
O número da solicitação, entre colchetes. Esse número corresponde à solicitação e à resposta.
Uma seta indicando se esta é uma solicitação (seta apontando para a direita) ou uma resposta (seta para a esquerda).
Para solicitações, a linha contém:
Para respostas, a linha contém:
Usando scripts pequenos, você pode extrair as informações necessárias do arquivo de log e reunir as estatísticas desejadas. Dessas, você pode ver quais páginas ou tipos de páginas estão lentas e se o desempenho geral é satisfatório.
As solicitações de pesquisa também são registradas no arquivo de log:
31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms
Assim, como acima, você pode usar scripts para extrair as informações relevantes e criar estatísticas.
No entanto, depois de determinar o tempo de resposta, talvez seja necessário analisar por que a solicitação está demorando e o que pode ser feito para melhorar a resposta.
Novamente, o request.log
pode ser usado para monitorar a simultaneidade e a reação do sistema a ela.
Devem ser feitos testes para determinar quantos usuários simultâneos o sistema pode lidar antes que um impacto negativo seja observado. Os scripts novamente podem ser usados para extrair resultados do arquivo de log:
31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms
AEM inclui várias ferramentas auxiliares localizadas em:
<cq-installation-dir>/crx-quickstart/opt/helpers
Um desses, rlog.jar
, pode ser usado para classificar rapidamente request.log
para que as solicitações sejam exibidas por duração, do mais longo ao mais curto tempo.
O seguinte comando mostra os possíveis argumentos:
$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
java -jar rlog.jar [options] <filename>
Options:
-h Prints this usage.
-n <maxResults> Limits output to <maxResults> lines.
-m <maxRequests> Limits input to <maxRequest> requests.
-xdev Exclude POST request to CRXDE.
Por exemplo, você pode executá-lo especificando o arquivo request.log
como um parâmetro e mostrar as 10 primeiras solicitações com a maior duração:
$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
Você pode precisar concatenar os arquivos individuais request.log
se precisar fazer essa operação em uma amostra de dados grande.
Para minimizar o impacto de casos especiais (como coleta de lixo, etc.), é recomendável usar uma ferramenta como apachebench
(consulte, por exemplo, ab para obter mais documentação) para ajudar a identificar vazamentos de memória e analisar seletivamente o tempo de resposta.
O Apache Bench pode ser usado da seguinte maneira:
$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503
Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes
Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106
Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)
Os números acima são obtidos de um notebook MAcBook Pro padrão (meados de 2010) acessando a página de empresa do geometrixx, conforme incluído em uma instalação padrão do AEM. A página é muito simples, mas não otimizada para desempenho.
apachebench
também exibe o tempo por solicitação como a média, em todas as solicitações simultâneas; consulte Time per request: 54.595 [ms]
(média, em todas as solicitações simultâneas). Você pode alterar o valor do parâmetro de simultaneidade -c
(número de várias solicitações a serem executadas de cada vez) para ver quaisquer efeitos.
As informações sobre o tráfego de solicitação (número de solicitações durante um período específico) fornecem uma indicação da carga da sua instância. Essas informações podem ser extraídas de request.log, embora o uso de contadores automatizará a coleta de dados para permitir que você veja:
Para automatizar a coleta de informações, também é possível instalar um RequestFilter para incrementar um contador em cada solicitação. Vários contadores podem ser usados para períodos diferentes.
As informações recolhidas podem ser utilizadas para indicar:
Recomenda-se que todos os projetos incluam html comments
para o desempenho do servidor. São muitos os bons exemplos públicos; selecione uma página, abra a fonte da página para exibição e role até a parte inferior, código como o seguinte pode ser visto:
</body>
</html>
<!--
Page took 58 milliseconds to be rendered by server
-->
O comando de ferramenta jconsole
está disponível com o JDK.
Start sua instância AEM.
Executar jconsole.
Selecione sua instância AEM e Connect.
No aplicativo Local
, clique com o duplo em com.day.crx.quickstart.Main
; a Visão geral será mostrada como padrão:
Depois disso, você pode selecionar outras opções.
Como o JDK 1.6, o comando de ferramenta jvisualvm
está disponível. Depois de instalar o JDK 1.6, você pode:
Start sua instância AEM.
Se estiver usando o Java 5, você pode adicionar o argumento -Dcom.sun.management.jmxremote
à linha de comando java que start sua JVM. O JMX é ativado por padrão com o Java 6.
Execute:
jvisualvm
: na pasta bin do JDK 1.6 (versão testada)visualvm
: pode ser baixado do VisualVM (versão de borda sangrando)No aplicativo Local
, clique com o duplo em com.day.crx.quickstart.Main
; a Visão geral será mostrada como padrão:
Depois disso, você pode selecionar outras opções, incluindo Monitor:
Você pode usar essa ferramenta para gerar despejos de thread e despejos de cabeçote de memória. Essas informações são frequentemente solicitadas pela equipe de suporte técnico.
Saber o máximo possível sobre a sua instalação pode ajudá-lo a rastrear o que pode ter causado uma mudança no desempenho e se essas alterações são justificadas. Essas métricas precisam ser coletadas em intervalos regulares para que você possa ver facilmente alterações significativas.
As seguintes informações podem ser úteis:
Para ver o número de autores que usaram o sistema desde a instalação, use a linha de comando:
cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l
Para ver o número de autores trabalhando em uma determinada data:
grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l
Para ver o número total de ativações de página desde a instalação do servidor, use um query de repositório; via CRXDE - Ferramentas - Query:
Tipo XPath
Caminho /
Query //element(*, cq:AuditEvent)[@cq:type='Activate']
Em seguida, calcule o número de dias decorridos desde a instalação para calcular a média.
Para ver o número de páginas atualmente no servidor, use um query de repositório; via CRXDE - Ferramentas - Query:
Tipo XPath
Caminho /
Query //element(*, cq:Page)
Para determinar o número total de implantações desde a instalação, use um query de repositório; via CRXDE - Ferramentas - Query:
Tipo XPath
Caminho /
Query //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']
Calcule o número de meses decorridos desde a instalação para calcular a média.
Para determinar o número total de Live Copies feitas desde a instalação, use um query de repositório; via CRXDE - Ferramentas - Query:
Tipo XPath
Caminho /
Query //element(*, cq:LiveSyncConfig)
Use novamente o número de meses decorridos desde a instalação para calcular a média.
Para ver quantos ativos DAM você mantém atualmente, use um query de repositório; via CRXDE - Ferramentas - Query:
Tipo XPath
Caminho /
Query /jcr:root/content/dam//element(*, dam:Asset)
Para determinar o tamanho total da pasta /var/dam
:
Use o WebDAV para mapear o repositório para o sistema de arquivos local.
Use a linha de comando:
cd /Volumes/localhost/var
du -sh dam/
Para obter o tamanho médio, divida o tamanho global pelo número total de ativos em /var/dam
(obtido acima).
Para ver o número de modelos atualmente no servidor, use um query de repositório; via CRXDE - Ferramentas - Query:
Tipo XPath
Caminho /
Query //element(*, cq:Template)
Para ver o número de componentes atualmente no servidor, use um query de repositório; via CRXDE - Ferramentas - Query:
Tipo XPath
Caminho /
Query //element(*, cq:Component)
Para determinar as solicitações por hora que você tem no sistema do autor em tempo de pico:
Para determinar o número total de solicitações desde a instalação, use a linha de comando:
cd <cq-installation-dir>/crx-quickstart/logs
grep -R "\->" request.log | wc -l
Para determinar as datas de start e término:
vim request.log
G / 1G: for the last/first lines
Use esses valores para calcular o número de horas decorridas desde a instalação e, em seguida, o número médio de solicitações por hora.
Repita o procedimento acima na instância de publicação.
Veja a seguir uma lista de sugestões sobre o que verificar se o start apresenta determinados problemas de desempenho. A lista não é (infelizmente) totalmente abrangente.
Consulte também os seguintes artigos para obter mais informações:
Se a CPU do seu sistema estiver constantemente em execução a 100%, então consulte:
A Base de conhecimento:
Embora esses erros devam ser detectados durante o Desenvolvimento e o Teste, alguns cenários podem se desviar.
Se o sistema estiver ficando sem memória, isso pode ser visto de várias maneiras, incluindo a degradação do desempenho e mensagens de erro, incluindo o subtexto:
java.lang.OutOfMemoryError
Nesses casos, verifique:
as configurações JVM usadas para start AEM
A Base de conhecimento:
Se o sistema estiver sem espaço em disco ou se você perceber que o disco está acabando, consulte:
Se você desabilitou a coleta de informações de depuração; isso pode ser configurado em vários locais, incluindo:
Se e como você configurou Expurgação de versão
A Base de conhecimento:
Se o desempenho de sua instância se deteriorar após cada reinicialização (às vezes uma semana ou mais), é possível verificar o seguinte:
A Base de conhecimento:
A Java Virtual Machine (JVM) melhorou significativamente em relação ao ajuste (especialmente desde o Java 7). Por esse motivo, a especificação de um tamanho JVM fixo razoável e o uso dos padrões será geralmente adequado.
Se as configurações padrão não forem adequadas, é importante estabelecer um método para monitorar e avaliar o desempenho do GC antes de tentar ajustar o JVM; isso pode envolver fatores de monitoramento, incluindo tamanho do heap, algoritmo e outros aspectos.
Algumas opções comuns são:
VerboseGC:
-verbose:gc \
-Xloggc:$LOGS/verbosegc.log \
-XX:+PrintGCDetails \
-XX:+PrintGCDateStamps
O log resultante pode ser assimilado por um visualizador de GC, como:
[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)
Ou JConsole:
Essas configurações são para uma conexão JMX "wide open":
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=8889 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false
Em seguida, conecte-se à JVM com o JConsole; consulte:
[https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html)
Isso ajudará você a ver quanta memória está sendo usada, quais algoritmos GC estão sendo usados, quanto tempo levam para serem executados e qual efeito isso tem no desempenho do aplicativo. Sem isso, o ajuste é apenas "botões de giro aleatório".
Para a VM Oracle, há também informações em:
https://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html