O processador é o único recurso da sua conta que não falha quando acaba: abranda. Não há mensagem de erro, não há página vermelha, não há aviso. O site continua a responder, só que devagar, e ninguém desconfia do processador porque o processador nunca se queixa. É por isso que este é o limite que mais gente atinge sem saber.
A mecânica geral dos limites está em os limites que não vêm no anúncio, e o que fazer a um site lento em geral está em o site está lento: o que faz mesmo diferença. Este artigo é sobre uma coisa só: o que está a gastar processador, e como se lhe tira o trabalho das mãos.
O que gasta processador, por ordem de peso
| A causa |
Porquê, e o que se vê |
| Construir a página de raiz a cada visita |
Sem cache, cada visitante obriga o servidor a correr o programa todo e a interrogar a base de dados outra vez, para chegar exactamente ao mesmo resultado. É de longe o maior desperdício, e o mais fácil de acabar. |
| Consultas pesadas à base de dados |
Listas de «relacionados», pesquisa interna, filtros de catálogo. Notam-se em páginas específicas, e não no site inteiro. |
| Robots a varrer o site |
Um robot que percorre o catálogo inteiro de dez em dez minutos gasta mais processador do que todos os seus clientes juntos, e não compra nada. |
| Tarefas agendadas a mais |
Uma tarefa de minuto a minuto que devia ser de hora a hora multiplica por sessenta o trabalho que faz. Ver tarefas agendadas. |
| Plugins que escrevem em cada visita |
Contadores, registos de visitas, mapas de calor. Cada visita passa a ser também uma escrita na base de dados. |
| Tratar imagens no servidor |
Enviar uma fotografia enorme faz o servidor gerar várias versões dela. Se o site faz isso a toda a hora, paga em processador. |
| Mandar e-mail dentro do pedido |
Um formulário que envia o e-mail antes de responder ao visitante prende o processo até o e-mail sair. |
O que fazer, pela ordem que paga mais
| 1 |
Ligue a cache, e a certa. Os nossos servidores correm LiteSpeed, e num site em WordPress isso quer dizer que o plugin certo é o LiteSpeed Cache: ele guarda a página pronta dentro do próprio servidor, antes de o PHP sequer arrancar. Um plugin de cache genérico não consegue fazer isso.
|
|
| 2 |
Ponha as tarefas do site numa tarefa agendada a sério. Muitos programas, o WordPress incluido, disparam as suas tarefas internas a partir das visitas: com pouco tráfego atrasam-se, com muito tráfego disparam a toda a hora. Passar isso para uma tarefa agendada do cPanel corta consumo e torna os horários previsíveis.
|
|
| 3 |
Reveja a frequência de tudo o que corre sozinho. Abra a lista de tarefas agendadas e pergunte-se, uma a uma, se aquela precisa mesmo de correr tão vezes. Quase nenhuma precisa.
|
|
| 4 |
Actualize a versão do PHP. O mesmo código corre visivelmente mais depressa numa versão recente, e mais depressa quer dizer menos processador por visita. Como se faz sem partir nada: mudar a versão do PHP sem partir o site.
|
|
| 5 |
Caçe o plugin culpado. Desligue metade, meça, e repita com a metade que sobra. Quatro ou cinco voltas chegam. Não é o número de plugins que conta: é o peso de cada um.
|
|
| 6 |
Limpe a base de dados. Revisões de textos antigos, tabelas de plugins já apagados, opções carregadas em todas as páginas. Numa base com anos, isto dá um ganho real. Com cópia feita antes.
|
|
|
Uma mudança de cada vez, com o número escrito antes e depois. Mudar cinco coisas ao mesmo tempo pode muito bem resultar, mas fica sem saber qual foi, e da próxima começa do zero. Como medir está em medir a velocidade do site.
|
Os robots, que são metade do problema e ninguém olha
Numa boa parte dos casos que nos chegam, a maioria dos pedidos ao site não vem de pessoas. Vem de motores de busca, de recolhedores de preços, de robôs de treino de modelos e de coisas piores. Contra isso há três níveis, por ordem de esforço.
| 1 |
Olhe primeiro. Nas estatísticas do cPanel vê quem mais pediu páginas e o quê. Ver estatísticas de visitas. Sem olhar, está a adivinhar.
|
|
| 2 |
Fale com os bem-comportados. Um ficheiro robots.txt com um pedido de espaçamento entre pedidos é respeitado pelos motores de busca sérios, e só por esses.
|
|
| 3 |
Ponha uma rede à frente. Um serviço como a Cloudflare filtra o que nunca chega a tocar no seu processador, e serve as imagens sem incomodar o servidor. Está explicado em Cloudflare: quando ajuda e como se liga.
|
|
|
Mudar de plano não cura um site mal feito. Um plano maior dá-lhe mais folga, não mais velocidade. Uma página que o próprio código demora a construir demora exactamente o mesmo numa máquina maior: o que muda é quantas dessas páginas cabem ao mesmo tempo. Se a página é o problema, o plano maior só adia a conversa e sobe a factura.
|
Quando já limpou tudo e o Resource Usage continua a bater no tecto com tráfego verdadeiro, aí sim o site cresceu para fora do plano. A decisão está arrumada em o que medir antes de mudar de plano.
PRODUTO RECOMENDADO Alojamento de sites com cPanel Domínio e SSL incluídos, cópias diárias e o painel que já conhece. desde 600,00 MT/mês Ver planos |
Português
English
