A Monitorização de Desempenho de Aplicações, para sites WordPress e WooCommerce, mostra-lhe para onde vai efetivamente o tempo do seu site: os percentis de tempo de resposta, os URLs mais lentos, as consultas de base de dados mais lentas e o quanto o PHP está a trabalhar. Este guia explica como ativar o APM, como ler cada painel e como agir com base no que mostra.
Onde Vive o APM no KPanel
- Inicie sessão no KPanel.
- Clique em Websites na barra lateral esquerda e, em seguida, clique no site.
- No menu esquerdo do site, abra Desempenho e depois APM.
O endereço direto é /websites/<site-id>/performance.
O APM é uma funcionalidade associada ao plano. Está incluído no Managed WordPress Pro. Em qualquer outro plano, a página mostra um painel de upgrade a explicar o que o APM cobre, em vez dos painéis de dados. Se vir esse painel, significa que a funcionalidade não está disponível no seu plano atual, e não que está desativada.
Ativar o APM
O APM está desativado até o ativar. Num plano elegível, a página mostra um cartão de Monitorização de Desempenho de Aplicações com um botão Ativar APM.
Ao ativá-lo, é adicionado um registo de acessos leve e um localizador de pedidos lentos ao nível do worker PHP. Não injeta nada nas suas páginas e não acrescenta trabalho ao pedido de um visitante, pelo que é seguro deixá-lo ligado permanentemente.
Depois de ativado, a página mostra um indicador APM Ativo com a data em que foi ligado, um botão Refresh e um botão Desativar APM. As métricas só aparecem depois de chegar tráfego real, por isso um site com pouca atividade mostra À espera de pedidos durante algum tempo.
Tempos de Resposta
O primeiro cartão contém quatro valores relativos à última hora, com o número de pedidos e a hora de captura no cabeçalho.
| Métrica | O que significa |
|---|---|
| Mediana (P50) | Metade dos pedidos foi mais rápida do que este valor |
| P95 | 95 por cento dos pedidos foram mais rápidos do que este valor |
| P99 | 99 por cento dos pedidos foram mais rápidos do que este valor |
| Taxa de Erro 5xx | A percentagem de pedidos que falharam com um erro de servidor |
Cada bloco tem um código de cores para que possa interpretar o estado sem conhecer os limiares.
Leia os percentis em conjunto, não isoladamente. Uma mediana boa com um P95 péssimo significa que a maioria dos pedidos está bem e uma minoria é dolorosa, o que é a assinatura clássica de uma página lenta, uma consulta lenta ou uma cache que falha em determinados URLs. Uma mediana má significa que o site inteiro está lento e a causa é normalmente estrutural: um plano subdimensionado, um tema pesado ou uma cache desativada.
A taxa de erro 5xx é o único valor que deveria ser zero. Qualquer valor sustentado acima de zero significa que os visitantes estão a ver falhas.
Workers PHP
O cartão Workers PHP mostra três números:
- Workers Ativos: quantos processos PHP estão atualmente a tratar pedidos.
- Pedidos Lentos: pedidos que excederam o limiar de pedido lento e foram registados.
- Total Tratado: ligações aceites desde que o conjunto foi iniciado.
Os workers ativos são um sinal de saturação. Se o valor se mantiver preso perto do seu limite máximo durante o tráfego normal, os pedidos estão em fila à espera do PHP, e todos os tempos de resposta mostrados no painel acima incluem, em parte, tempo de espera em fila. Trata-se de um problema de capacidade, não de código, e a solução passa por um plano maior ou menos trabalho por pedido.
Um número crescente de pedidos lentos com um volume de pedidos estável significa que algo se tornou dispendioso.
Endpoints Mais Lentos
Este cartão lista os seus URLs mais lentos por tempo de resposta P95, cada um com uma barra, o P95 em milissegundos e quantas chamadas recebeu. A cor assinala os piores infratores.
Leia isto como uma lista restrita, não como uma tabela classificativa. O que interessa é a interseção entre lento e frequentemente chamado: uma página que demora quatro segundos e é acedida duas vezes por dia importa muito menos do que uma que demora 900 milissegundos e é acedida dez mil vezes.
Causas comuns:
- Páginas de pesquisa que percorrem dados sem um índice.
- Listagens de categorias e arquivos que constroem consultas grandes por pedido.
- Páginas de carrinho, checkout e conta, que nunca são colocadas em cache por serem específicas de cada visitante. Consulte Site Caching para saber quais os caminhos que contornam a cache propositadamente.
- URLs de administração, que são sempre dinâmicos.
- Qualquer chamada a uma API externa dentro do pedido, em que está a medir o servidor de outra pessoa.
Consultas Lentas
O cartão Consultas Lentas lista as consultas de base de dados com uma média superior a 100 milissegundos, obtidas a partir dos próprios dados de desempenho da base de dados. Cada linha mostra o tempo médio, o tempo máximo, o número de chamadas e o texto normalizado da consulta.
O texto da consulta é um resumo, com os valores literais removidos, pelo que a mesma consulta com parâmetros diferentes é agrupada numa única linha. É isto que torna o número de chamadas significativo.
Corrigir consultas lentas costuma resolver-se de uma de três formas: adicionar um índice de que a consulta necessita, reduzir a frequência com que a consulta é executada colocando o resultado em cache, ou remover o plugin que a gera. Uma consulta com um número de chamadas muito elevado e uma média moderada é muitas vezes pior no total do que um único caso extremo dramático.
Se tanto a lista de endpoints como a de consultas aparecerem vazias, o cartão indica que não foram detetados pedidos lentos, o que significa que tudo na última hora esteve dentro dos limiares normais.
Tirar Bom Proveito do APM
Estabeleça uma base de referência. Observe os números quando o site está saudável, para saber como é o normal. Um P95 de 700 milissegundos não significa nada até saber que costumava ser 300.
Altere uma coisa de cada vez. Ative uma cache, atualize e compare. Desative um plugin suspeito, atualize e compare. Alterações em lote não lhe dão nenhum sinal útil.
Atualize de forma deliberada. O botão Refresh volta a ler as métricas a pedido. Os valores abrangem a última hora, por isso dê alguma margem de tempo a uma alteração antes de a avaliar.
Olhe também para além do APM. O APM mede a sua aplicação. Se o problema estiver na rede ou na periferia (edge) em vez de no código, o Site Traffic Analytics e a Site Uptime Monitoring vão mostrá-lo em vez disso.
Resolução de Problemas
A página mostra um painel de upgrade. O APM está incluído no Managed WordPress Pro. Nos outros planos não está disponível.
O APM está ativado mas não há métricas. Ainda não há tráfego. As métricas aparecem assim que o site recebe pedidos.
Os tempos de resposta estão bem no APM mas o site parece lento. O APM mede apenas o tempo do lado do servidor. O tempo gasto a descarregar imagens, a executar JavaScript e a carregar tipos de letra no navegador é invisível aqui. Se o tempo de servidor é bom e a página continua a parecer lenta, o problema está na interface ou no que está a pedir ao navegador para obter.
O P95 piorou depois de uma atualização de plugin. Verifique primeiro a lista dos endpoints mais lentos e depois a lista das consultas lentas. Um plugin que acrescentou uma consulta a cada carregamento de página vai aparecer em ambas.
Está tudo lento o tempo todo. Verifique primeiro a saturação dos workers PHP. Se os workers estiverem no limite, acrescente capacidade ou reduza o trabalho por pedido antes de otimizar qualquer outra coisa.
Erros acima de zero. Corrija estes antes de perseguir milissegundos. Comece pelos seus registos (logs) e utilize o botão Troubleshoot with Kora no separador Páginas de erro do site, que pede a Kora para ler os seus registos de erros e falhas recentes por si. Consulte Custom Error Pages.
Páginas Relacionadas
- Site Caching costuma ser o maior ganho individual para um site WordPress.
- Site Security para deteção de vulnerabilidades e malware no mesmo site.
- Fazer uma Cópia de Segurança antes de começar a remover plugins.