Evitando o desastre do CMS: como evitar o tempo de inatividade do site

O que realmente significa para um site ser considerado inativo ?

Muitas vezes isso depende de quem você pergunta.

Para um site ser considerado inativo, isso pode significar várias coisas diferentes:

• O site está completamente indisponível.
• O site está online, mas inutilmente lento.
• O site está dando mensagens de erro para determinados usuários ou locais.
• O site está funcionando para a maioria dos visitantes, mas alguns simplesmente não conseguem fazer login no CMS, por exemplo, para criar, editar ou publicar conteúdo.

Não importa a causa ou o grau, o impacto do tempo de inatividade do site pode ser sério, desde pedidos perdidos de comércio eletrônico e usuários frustrados até a confiança enfraquecida do cliente.

No terceiro de nossa série Evitando o desastre do CMS , exploramos as causas clássicas do tempo de inatividade do site e o papel que o monitoramento contínuo e outros fatores desempenham para evitar isso.

Primeiro, o papel que o monitoramento contínuo desempenha

Monitoramos diferentes aspectos de um site, para que possamos saber quando algo não está funcionando corretamente em qualquer uma das diferentes camadas que compõem nossa plataforma WordPress VIP totalmente gerenciada. Essas camadas incluem:

• Conectividade de rede
• Balanceadores de carga
• Servidores da web
• Cache de objetos (Memcached)
• Bancos de dados
• Elasticsearch
• Serviço de Arquivos (CDN)

Tentamos identificar problemas com antecedência para que possamos antecipar problemas futuros que possam afetar a estabilidade do site. Registros de referência cruzada de diferentes componentes do sistema nos permitem revisar os períodos em que um site foi relatado como instável. Como uma combinação de fatores em vez de um único problema pode ser responsável pelo tempo de inatividade, empregamos várias ferramentas para comparar dados entre sistemas e aplicativos.

Na maioria dos casos, a instabilidade do site é resultado do código do aplicativo, ou seja, tema WordPress personalizado ou de terceiros e código do plugin. Aqui estão algumas coisas que procuramos ao investigar um site instável e como mitigar cada uma delas.

Não há cache suficiente

A coisa mais importante que você pode fazer para garantir que um site tenha desempenho e estabilidade é garantir que qualquer página inteira que possa ser armazenada em cache seja armazenada em cache. As páginas sem cache precisam ser criadas no servidor cada vez que são solicitadas, o que é um processo mais lento e mais propenso a erros.

A resposta do WordPress VIP:

A Plataforma VIP do WordPress fornece cache de página poderoso por meio de uma rede global de servidores de cache de borda, cada um usado para armazenar e fornecer conteúdo mais próximo de um usuário final. O tempo de resposta de um servidor de cache de borda é quase sempre muito mais rápido do que qualquer coisa que ignore o cache de página e atinja os servidores de origem.

Desafios de armazenamento em cache

Como eles exigem uma experiência personalizada e totalmente interativa, alguns sites, principalmente os de comércio eletrônico, simplesmente não podem ser armazenados em cache no nível do cache da página.

Muitas vezes, um compromisso pode ser encontrado em que uma página estática é servida pelo cache de borda, com recursos dinâmicos (por exemplo, status de login, carrinhos de compras) adicionados via JavaScript. As solicitações assíncronas do JavaScript podem ser usadas para se comunicar com um endpoint da API REST do WordPress projetado com uma sobrecarga muito menor do que um carregamento de página completo.

Alternativamente, é aqui que o cache de objetos entra em ação. A página pode permanecer dinâmica, mas partes da página e quaisquer dados usados ​​nela podem ser armazenados e recuperados no cache de objetos para evitar a necessidade de consultar o banco de dados.

A resposta do WordPress VIP:

Cada ambiente de aplicativo WordPress VIP tem seu próprio cluster Memcached dedicado, que armazena dados de cache de objetos na memória para uma recuperação extremamente rápida e eficiente.

Implantações de código não testadas

Este é outro culpado comum do tempo de inatividade do site e muito fácil de diagnosticar, com base na pura causa e efeito.

Se o seu site acabou de implantar um código não testado, causando problemas imediatos no site, essa é a causa provável. Se puder, reverta o código suspeito para a versão anterior o mais rápido possível.

A melhor coisa a fazer para evitar essa situação? Teste minuciosamente cada parte do código em um ambiente separado de desenvolvimento ou preparação antes de liberar para produção.

A resposta do WordPress VIP:

Como todas as implantações do nosso site são via GitHub, os clientes VIP do WordPress podem reverter o código facilmente, sem perder nenhuma nova alteração de código, que permanece armazenada com segurança no histórico de revisões do GitHub. Opcionalmente, em situações de emergência, podemos reverter o site de um cliente para uma implantação anterior em seu nome, independentemente do GitHub.

Em relação aos ambientes, todos os aplicativos hospedados em nosso serviço totalmente gerenciado podem ter um ambiente separado de desenvolvimento ou teste. A sincronização de dados da produção é fácil, permitindo que você teste o código com a mesma quantidade e o mesmo tipo de dados do seu site de produção.

Erros PHP

WordPress usa código PHP no servidor. Um erro de PHP pode ser “fatal”, o que significa que, uma vez que o erro ocorra, a página da web, script ou comando parará de ser executado. Eles quase sempre aparecerão como erros visíveis em algum lugar e serão registrados nos logs do PHP.

Nota: Alguns avisos do PHP no PHP 7 se tornam erros fatais no PHP 8, então é importante levar esses erros a sério.

A resposta do WordPress VIP (mais conselhos úteis):

Nossa plataforma registra automaticamente todos os erros de PHP, disponibilizando-os para clientes VIP do WordPress em seu painel e para nossos engenheiros.

Dica profissional : resolva e corrija todos os erros do PHP, mesmo que um site pareça estar funcionando bem. Rotineiramente, vemos logs cheios de erros PHP, até mesmo fatais, em um site que parece estável. No entanto, isso não significa necessariamente que o site esteja funcionando corretamente . Manter os logs do PHP limpos, abordando pequenos erros e avisos, facilita a localização de erros mais sérios durante a depuração.

Consultas lentas ao banco de dados MySQL

Todo site WordPress usa um banco de dados para armazenar o conteúdo do site e os dados de configuração. As consultas de banco de dados buscam esses dados de conteúdo para páginas da Web, mas às vezes essas consultas são gravadas de forma ineficiente. Eles podem funcionar bem para sites com apenas algumas centenas de páginas, mas travam ao lidar com grandes quantidades de dados (alguns sites em nossa plataforma têm milhões de registros armazenados).

Uma consulta lenta limita os recursos do banco de dados, afetando potencialmente a estabilidade do site — não apenas para a página, script ou comando que executa o SQL, mas em todo o aplicativo. Os sites geralmente sofrem porque as consultas de banco de dados únicas ou múltiplas são lentas, por exemplo, qualquer consulta que leve mais de 0,75 segundos para ser executada.

A resposta do WordPress VIP:

O WordPress VIP ajuda a mitigar os gargalos do banco de dados fornecendo a cada aplicativo um cluster de banco de dados dedicado com um banco de dados primário, onde ocorrem todas as consultas de gravação do banco de dados e um ou mais bancos de dados de réplica somente leitura. Isso aumenta o número de consultas simultâneas ao banco de dados que podem ocorrer, distribuindo a carga de recursos quando um site está sob pressão. Dito isso, as consultas de banco de dados lentas nem sempre podem ser resolvidas simplesmente adicionando recursos de banco de dados adicionais. É por isso que aconselhamos os clientes a monitorar consultas lentas ao banco de dados usando o Query Monitor e o New Relic (fornecidos por nossa plataforma). Eles destacam onde as consultas se originam no banco de dados, para que sua equipe de desenvolvimento possa refatorá-las para otimizar o desempenho.

Por fim, nossos engenheiros de suporte a aplicativos e Premier também podem ajudar sua equipe a encontrar e analisar essas consultas e sugerir maneiras de aprimorá-las em termos de velocidade e eficiência.

Gravações excessivas no banco de dados

Às vezes, um recurso, como registro personalizado ou código de rastreamento, atualiza o banco de dados a cada solicitação. Isso pode levar à instabilidade por dois motivos:

• Réplicas de banco de dados anteriores: Todas as consultas de gravação são direcionadas ao banco de dados primário; consultas de banco de dados subsequentes para a mesma tabela (ou tabelas) na mesma solicitação de página também serão direcionadas para lá. Ao não aproveitar as réplicas de banco de dados, isso limita a escalabilidade do site.
• Ignorando o cache de página : Para que uma gravação de banco de dados aconteça em cada solicitação de página, o cache de página deve ser ignorado. Mas fazer isso significa que a primeira (e melhor) linha de defesa foi comprometida.

A resposta do WordPress VIP:

Nessas circunstâncias, recomendamos refatorar o recurso. Por exemplo, a análise de conteúdo geralmente é melhor delegada a um serviço externo que usa um snippet de JavaScript na página em vez de código do lado do servidor, que não funciona bem com armazenamento em cache e pode resultar em gravações excessivas no banco de dados.

Outras causas conhecidas de tempo de inatividade e como evitá-las

Plug-ins

Existem milhares de plugins de terceiros populares e úteis no ecossistema WordPress que fornecem recursos e funcionalidades fantásticos. Alguns, no entanto, têm desafios de dimensionamento, potencialmente levando a problemas de tempo de inatividade quando adicionados a um site com muito conteúdo e tráfego.

A resposta do WordPress VIP:

Como bons administradores do ecossistema, contatamos regularmente os fornecedores com sugestões para melhorar o desempenho de seus plug-ins em ambientes de alto tráfego. Também podemos sugerir plugins alternativos que foram experimentados e testados em escala em nossa plataforma.

Registro personalizado

O log personalizado é uma ferramenta de depuração poderosa, geralmente o único método viável para rastrear um bug ou problema que parece ocorrer apenas em um site de produção. Em várias ocasiões, no entanto, vimos o log personalizado construído em PHP em um site de alto tráfego tornar as coisas mais lentas ou colocar um site em risco de inatividade devido a gravações excessivas no banco de dados.

A resposta do WordPress VIP:

Para os clientes, fornecemos acesso a logs PHP padrão no painel Health do painel do aplicativo WordPress VIP. Lá eles podem registrar erros personalizados (e também no New Relic), o que não afetará negativamente o banco de dados.

Chamadas de API remotas

Alguns sites aproveitam as chamadas da API REST do lado do servidor para outros aplicativos ou serviços. Eles são bastante rápidos em circunstâncias normais, mas às vezes o código do aplicativo subjacente leva a uma resposta lenta, atinge o tempo limite ou gera um erro.

A resposta do WordPress VIP:

Para minimizar esses problemas, aconselhamos “codificação defensiva”. Depende da finalidade da chamada remota, mas geralmente quando uma solicitação remota falha, é possível retornar a uma resposta em cache de uma solicitação anterior — ou pelo menos “lidar com o erro de maneira adequada”, para que o restante da página possa ainda carrega. Fornecemos várias funções auxiliares para lidar com esses cenários. Manter um tempo limite baixo também significa que os recursos PHP são liberados mais rapidamente se a API remota não estiver respondendo.

Leia mais em nossa série Evitando desastres de CMS

Quando sua empresa está em risco, você não pode se dar ao luxo de enviar novos negócios para outro lugar e manchar sua marca fazendo com que seu sistema de gerenciamento de conteúdo (CMS) forneça uma experiência digital ruim. Em Como melhorar o desempenho do site , diagnosticamos cinco culpados comuns de lentidão e como turbinar as coisas usando um CMS ágil.

Dias de alto tráfego devem ser motivo de comemoração, não um pesadelo para engenheiros em seu pé traseiro coletivo tentando manter um site e aplicativos funcionando e funcionando para lidar com a carga - e sua reputação intacta. Em Scaling WordPress for High Traffic , exploramos quatro abordagens para permitir que um site WordPress lide com essas ondas de tráfego.