Evitar el desastre de CMS: cómo prevenir el tiempo de inactividad del sitio web

¿Qué significa realmente que un sitio se considere inactivo ?

A menudo eso depende de a quién le preguntes.

Para que un sitio web se considere inactivo, puede significar una serie de cosas diferentes:

• El sitio web no está disponible por completo.
• El sitio web está en línea pero inutilizablemente lento.
• El sitio web muestra mensajes de error para ciertos usuarios o ubicaciones.
• El sitio web funciona para la mayoría de los visitantes, pero algunos simplemente no pueden iniciar sesión en su CMS, por ejemplo, para crear, editar o publicar contenido.

Independientemente de la causa o el grado, el impacto del tiempo de inactividad del sitio web puede ser grave, desde pedidos de comercio electrónico perdidos y usuarios frustrados hasta una confianza debilitada del cliente.

En la tercera parte de nuestra serie Evitar desastres de CMS , exploramos las causas fundamentales clásicas del tiempo de inactividad del sitio web y el papel que desempeñan el monitoreo continuo y otros factores para evitarlo.

Primero, el papel que juega el monitoreo continuo

Supervisamos diferentes aspectos de un sitio web, por lo que podemos saber cuándo algo no funciona correctamente en cualquiera de las diferentes capas que componen nuestra plataforma VIP de WordPress completamente administrada. Esas capas incluyen:

• Conectividad de red
• Equilibradores de carga
• servidores web
• Caché de objetos (Memcached)
• bases de datos
• Elasticsearch
• Servicio de archivos (CDN)

Intentamos detectar problemas con anticipación para poder anticipar problemas futuros que puedan afectar la estabilidad del sitio web. Los registros de referencias cruzadas de diferentes componentes del sistema nos permiten revisar los períodos en los que se informó que un sitio web era inestable. Debido a que una combinación de factores en lugar de un solo problema puede ser responsable del tiempo de inactividad, empleamos una serie de herramientas para comparar datos entre sistemas y aplicaciones.

En la mayoría de los casos, la inestabilidad del sitio web es el resultado del código de la aplicación, es decir, un tema de WordPress personalizado o de terceros y un código de complemento. Aquí hay algunas cosas que buscamos cuando investigamos un sitio inestable y cómo mitigar cada una.

Almacenamiento en caché insuficiente

Lo más importante que puede hacer para asegurarse de que un sitio tenga un buen rendimiento y sea estable es asegurarse de que cualquier página completa que se pueda almacenar en caché se almacene en caché. Las páginas no almacenadas en caché deben crearse en el servidor cada vez que se solicitan, lo que es un proceso más lento y más propenso a errores.

La respuesta VIP de WordPress:

La plataforma VIP de WordPress proporciona un potente almacenamiento en caché de páginas a través de una red global de servidores de caché perimetrales, cada uno de los cuales se utiliza para almacenar y servir contenido más cercano a un usuario final. El tiempo de respuesta de un servidor de caché perimetral es casi siempre mucho más rápido que cualquier cosa que omita el almacenamiento en caché de la página y llegue a los servidores de origen.

Desafíos de almacenamiento en caché

Debido a que exigen una experiencia totalmente interactiva y personalizada, algunos sitios, en particular los de comercio electrónico, simplemente no se pueden almacenar en caché en el nivel de caché de página.

A menudo, se puede encontrar un compromiso por el cual una página estática se sirve mediante caché perimetral, con características dinámicas (por ejemplo, estado de inicio de sesión, carritos de compras) agregadas a través de JavaScript. Las solicitudes asincrónicas de JavaScript se pueden usar para comunicarse con un punto final de la API REST de WordPress diseñado con una sobrecarga mucho menor que una carga de página completa.

Alternativamente, aquí es donde entra en juego el almacenamiento en caché de objetos. La página puede permanecer dinámica, pero partes de la página y los datos utilizados en ella se pueden almacenar y recuperar en la memoria caché de objetos para evitar la necesidad de consultar la base de datos.

La respuesta VIP de WordPress:

Cada entorno de aplicación VIP de WordPress tiene su propio clúster Memcached dedicado, que almacena datos de caché de objetos en la memoria para una recuperación rápida y eficiente.

Implementaciones de código no probado

Este es otro culpable común del tiempo de inactividad del sitio web y bastante fácil de diagnosticar, basado en pura causa y efecto.

Si su sitio web acaba de implementar un código no probado, lo que genera problemas inmediatos en el sitio, esa es su causa probable. Si puede, revierta el código sospechoso a la versión anterior lo antes posible.

¿Qué es lo mejor que se puede hacer para evitar esta situación? Pruebe minuciosamente cada fragmento de código en un entorno de desarrollo o ensayo independiente antes de lanzarlo a producción.

La respuesta VIP de WordPress:

Debido a que todas las implementaciones de nuestro sitio se realizan a través de GitHub, los clientes VIP de WordPress pueden revertir fácilmente el código ellos mismos, sin perder ningún cambio de código nuevo, que permanece almacenado de forma segura en el historial de revisión de GitHub. Opcionalmente, en situaciones de emergencia, podemos revertir el sitio web de un cliente a una implementación anterior en su nombre, independientemente de GitHub.

Con respecto a los entornos, todas las aplicaciones alojadas en nuestro servicio completamente administrado pueden tener un entorno de desarrollo o ensayo independiente. La sincronización de datos allí desde la producción es fácil, lo que le permite probar el código con la misma cantidad y el mismo tipo de datos que en su sitio web de producción.

errores PHP

WordPress usa código PHP en el servidor. Un error de PHP puede ser "fatal", lo que significa que una vez que ocurre el error, la página web, el script o el comando dejarán de ejecutarse. Estos casi siempre aparecerán como errores visibles en algún lugar y se registrarán en los registros de PHP.

Nota: Algunas advertencias de PHP en PHP 7 se convierten en errores fatales en PHP 8, por lo que es importante tomar estos errores en serio.

La respuesta VIP de WordPress (más consejos útiles):

Nuestra plataforma registra automáticamente todos los errores de PHP, poniéndolos a disposición de los clientes VIP de WordPress en su tablero y para nuestros ingenieros.

Consejo profesional : aborde y corrija todos los errores de PHP, incluso si un sitio parece funcionar bien. Rutinariamente, vemos registros llenos de errores de PHP, incluso fatales, en un sitio que parece estable. Sin embargo, eso no significa necesariamente que el sitio esté funcionando correctamente . Mantener limpios los registros de PHP al abordar errores menores y advertencias hace que sea más fácil encontrar errores más graves durante la depuración.

Consultas de base de datos MySQL lentas

Cada sitio web de WordPress utiliza una base de datos para almacenar el contenido del sitio web y los datos de configuración. Las consultas de la base de datos obtienen los datos de contenido de las páginas web, pero a veces esas consultas se escriben de manera ineficiente. Pueden funcionar bien para sitios con solo unos pocos cientos de páginas, pero se bloquean cuando manejan grandes cantidades de datos (algunos sitios web en nuestra plataforma tienen millones de registros almacenados).

Una consulta lenta ocupa los recursos de la base de datos, lo que podría afectar la estabilidad del sitio, no solo para la página, el script o el comando que ejecuta el SQL, sino en toda la aplicación. Los sitios suelen tener problemas porque las consultas de bases de datos únicas o múltiples son lentas, por ejemplo, cualquier consulta que tarde más de 0,75 segundos en ejecutarse.

La respuesta VIP de WordPress:

WordPress VIP ayuda a mitigar los cuellos de botella de la base de datos al proporcionar a cada aplicación un clúster de base de datos dedicado que presenta una base de datos principal, donde ocurren todas las consultas de escritura de la base de datos y una o más bases de datos de réplica de solo lectura. Esto aumenta la cantidad de consultas simultáneas a la base de datos que pueden realizarse, lo que distribuye la carga de recursos cuando un sitio está bajo presión. Dicho esto, las consultas de base de datos lentas no siempre se pueden resolver simplemente agregando recursos de base de datos adicionales. Es por eso que recomendamos a los clientes que controlen las consultas lentas de la base de datos utilizando Query Monitor y New Relic (proporcionado por nuestra plataforma). Estos resaltan dónde se originan las consultas en la base de datos, por lo que su equipo de desarrollo puede refactorizarlas para optimizar el rendimiento.

Finalmente, nuestro Soporte de Aplicaciones e Ingenieros Premier también pueden ayudar a su equipo a encontrar y analizar estas consultas, y sugerir formas de mejorarlas para lograr velocidad y eficiencia.

Escrituras excesivas en la base de datos

A veces, una característica, como el registro personalizado o el código de seguimiento, actualiza la base de datos en cada solicitud. Esto puede conducir a la inestabilidad por dos razones:

• Réplicas de bases de datos anteriores : todas las consultas de escritura se dirigen a la base de datos principal; las consultas posteriores de la base de datos para la misma tabla (o tablas) en la misma solicitud de página también se dirigirán allí. Al no aprovechar las réplicas de la base de datos, esto limita la escalabilidad del sitio.
• Omitir el almacenamiento en caché de la página : para que se produzca una escritura en la base de datos en cada solicitud de página, se debe omitir el almacenamiento en caché de la página. Pero hacerlo significa que la primera (y mejor) línea de defensa se ha visto comprometida.

La respuesta VIP de WordPress:

En estas circunstancias, recomendamos refactorizar la función. Por ejemplo, el análisis de contenido suele delegarse mejor en un servicio externo que use un fragmento de JavaScript en la página en lugar de un código del lado del servidor, que no funciona bien con el almacenamiento en caché y puede generar escrituras excesivas en la base de datos.

Otras causas conocidas de tiempo de inactividad y cómo evitarlas

Complementos

Hay miles de complementos de terceros populares y útiles en el ecosistema de WordPress que brindan características y funcionalidades fantásticas. Algunos, sin embargo, tienen desafíos para escalar, lo que puede generar problemas de tiempo de inactividad cuando se agregan a un sitio web con toneladas de contenido y tráfico.

La respuesta VIP de WordPress:

Como buenos administradores del ecosistema, contactamos regularmente a los proveedores con sugerencias para que sus complementos funcionen mejor en entornos de alto tráfico. También podemos sugerir complementos alternativos que se han probado y probado a escala en nuestra plataforma.

Registro personalizado

El registro personalizado es una poderosa herramienta de depuración, a menudo el único método viable para rastrear un error o problema que parece ocurrir solo en un sitio de producción. En numerosas ocasiones, sin embargo, hemos visto que el registro personalizado integrado en PHP en un sitio de alto tráfico ralentiza las cosas o pone un sitio en peligro de tiempo de inactividad debido a escrituras excesivas en la base de datos.

La respuesta VIP de WordPress:

Para los clientes, brindamos acceso a los registros estándar de PHP en el panel de Salud del panel de aplicaciones VIP de WordPress. Allí pueden registrar errores personalizados (y también en New Relic), lo que no afectará negativamente a la base de datos.

Llamadas API remotas

Algunos sitios web aprovechan las llamadas API REST del lado del servidor a otras aplicaciones o servicios. Estos son bastante rápidos en circunstancias normales, pero a veces el código de la aplicación subyacente genera una respuesta lenta, se agota el tiempo de espera o genera un error.

La respuesta VIP de WordPress:

Para minimizar estos problemas, recomendamos "codificación defensiva". Depende del propósito de la llamada remota, pero a menudo, cuando falla una solicitud remota, es posible recurrir a una respuesta almacenada en caché de una solicitud anterior, o al menos "manejar el error con gracia", para que el resto de la página pueda todavía carga. Proporcionamos una serie de funciones auxiliares para manejar estos escenarios. Mantener un tiempo de espera bajo también significa que los recursos de PHP se liberan más rápido si la API remota no responde.

Lea más en nuestra serie Cómo evitar desastres de CMS

Cuando su negocio está en juego, no puede permitirse el lujo de enviar nuevos negocios a otra parte y empañar su marca al hacer que su sistema de administración de contenido (CMS) brinde una experiencia digital deficiente. En Cómo mejorar el rendimiento del sitio web , diagnosticamos cinco culpables comunes de la ralentización y cómo potenciar las cosas con un CMS ágil.

Los días de mucho tráfico deben ser motivo de celebración, no una pesadilla para los ingenieros que intentan mantener un sitio y aplicaciones en funcionamiento para manejar la carga y su reputación intacta. En Escalar WordPress para tráfico alto , exploramos cuatro enfoques para permitir que un sitio web de WordPress maneje esos maremotos de tráfico.