Cómo solucionar problemas de un servidor sobrecargado

Cómo determinar un cuello de botella de un servidor, corregirlo rápidamente, mejorar el rendimiento del servidor y prevenir regresiones

Katie Hempenius
Katie Hempenius
X

Descripción general

En esta guía, se muestra cómo corregir un servidor sobrecargado en 4 pasos:

  1. Evalúa: Determina el cuello de botella del servidor.
  2. Estabilizar: Implementa correcciones rápidas para mitigar el impacto.
  3. Mejora: Aumenta y optimiza las capacidades del servidor.
  4. Supervisa: Usa herramientas automatizadas para evitar problemas futuros.

Evaluación

Cuando el tráfico sobrecarga un servidor, uno o más de los siguientes elementos pueden convertirse en un cuello de botella: CPU, red, memoria o E/S de disco. Identificar cuál de estos es el cuello de botella permite enfocar los esfuerzos en las mitigaciones más impactantes.

  • CPU: Se debe investigar y corregir el uso de CPU que supera el 80% de forma constante. El rendimiento del servidor suele degradarse una vez que el uso de la CPU alcanza alrededor del 80% al 90% y se vuelve más pronunciado a medida que el uso se acerca al 100%. El uso de la CPU para entregar una sola solicitud es despreciable, pero hacerlo a la escala que se encuentra durante los aumentos repentinos del tráfico puede abrumar a un servidor. Transferir la entrega a otra infraestructura, reducir las operaciones costosas y limitar la cantidad de solicitudes reducirá el uso de la CPU.
  • Red: Durante los períodos de tráfico alto, la capacidad de procesamiento de la red necesaria para entregar las solicitudes de los usuarios puede exceder la capacidad. Algunos sitios, según el proveedor de hosting, también pueden alcanzar límites en cuanto a la transferencia de datos acumulativa. Reducir el tamaño y la cantidad de datos que se transfieren desde y hacia el servidor quitará este cuello de botella.
  • Memoria: Cuando un sistema no tiene suficiente memoria, los datos se deben transferir al disco para su almacenamiento. El acceso al disco es considerablemente más lento que el de la memoria, lo que puede ralentizar toda una aplicación. Si la memoria se agota por completo, se pueden producir errores de memoria insuficiente (OOM). Ajustar la asignación de memoria, corregir las fugas de memoria y actualizar la memoria puede quitar este cuello de botella.
  • E/S de disco: La velocidad a la que se pueden leer o escribir datos desde el disco está limitada por el propio disco. Si la E/S de disco es un cuello de botella, aumentar la cantidad de datos almacenados en caché en la memoria puede aliviar este problema (a costa de un mayor uso de la memoria). Si esto no funciona, es posible que debas actualizar los discos.

Las técnicas de esta guía se enfocan en abordar los cuellos de botella de la CPU y la red. En la mayoría de los sitios, la CPU y la red serán los cuellos de botella más relevantes durante un aumento repentino del tráfico.

Ejecutar top en el servidor afectado es un buen punto de partida para investigar los cuellos de botella. Si está disponible, complementa esta información con datos históricos de tu proveedor de hosting o herramientas de supervisión.

Estabilizar

Un servidor sobrecargado puede provocar rápidamente fallas en cascada en otras partes del sistema. Por lo tanto, es importante estabilizar el servidor antes de intentar realizar cambios más significativos.

Límite de frecuencia

El límite de frecuencia protege la infraestructura, ya que limita la cantidad de solicitudes entrantes. Esto es cada vez más importante a medida que se degrada el rendimiento del servidor: a medida que aumentan los tiempos de respuesta, los usuarios tienden a actualizar la página de forma agresiva, lo que aumenta aún más la carga del servidor.

Corregir

Aunque rechazar una solicitud es relativamente económico, la mejor manera de proteger tu servidor es controlar el límite de frecuencia en algún lugar anterior a él, por ejemplo, a través de un balanceador de cargas, un proxy inverso o una CDN.

Instrucciones:

Material de lectura adicional:

Almacenamiento en caché HTTP

Busca formas de almacenar en caché el contenido de forma más agresiva. Si un recurso se puede entregar desde una caché HTTP (ya sea la caché del navegador o una CDN), no es necesario solicitarlo al servidor de origen, lo que reduce la carga del servidor.

Los encabezados HTTP, como Cache-Control, Expires y ETag, indican cómo una caché HTTP debe almacenar en caché un recurso. La auditoría y corrección de estos encabezados mejorará la caché.

Aunque los service workers también se pueden usar para la caché, utilizan una caché independiente y son un complemento, en lugar de un reemplazo, para la caché HTTP adecuada. Por este motivo, cuando se controla un servidor sobrecargado, los esfuerzos deben enfocarse en optimizar la caché de HTTP.

Diagnosticar

Ejecuta Lighthouse y consulta la auditoría Aloja elementos estáticos con una política de caché eficiente para ver una lista de recursos con un tiempo de actividad (TTL) corto o medio. Para cada recurso de la lista, considera si se debe aumentar el TTL. A modo de guía aproximada, ten en cuenta lo siguiente:

  • Los recursos estáticos deben almacenarse en caché con un TTL largo (1 año).
  • Los recursos dinámicos deben almacenarse en caché con un TTL corto (3 horas).

Corregir

Establece la directiva max-age del encabezado Cache-Control en la cantidad correcta de segundos.

Instrucciones:

Degradación elegante

La degradación elegante es la estrategia de reducir temporalmente la funcionalidad para eliminar el exceso de carga de un sistema. Este concepto se puede aplicar de muchas maneras diferentes: por ejemplo, publicar una página de texto estático en lugar de una aplicación con todas las funciones, inhabilitar la búsqueda o mostrar menos resultados de la búsqueda, o inhabilitar ciertas funciones costosas o no esenciales. Se debe hacer hincapié en quitar las funciones que se pueden quitar de forma segura y sencilla con un impacto mínimo en el negocio.

Mejora

Usa una red de distribución de contenidos (CDN)

La entrega de recursos estáticos se puede transferir de tu servidor a una red de distribución de contenido (CDN), lo que reduce la carga.

La función principal de una CDN es entregar contenido a los usuarios rápidamente mediante una gran red de servidores que se encuentran cerca de ellos. Sin embargo, la mayoría de las CDN también ofrecen funciones adicionales relacionadas con el rendimiento, como compresión, balanceo de cargas y optimización de contenido multimedia.

Configura una CDN

Las CDN se benefician de la escala, por lo que rara vez tiene sentido operar tu propia CDN. Una configuración básica de CDN es bastante rápida de configurar (~30 minutos) y consiste en actualizar los registros DNS para que apunten a la CDN.

Optimiza el uso de la CDN

Diagnosticar

Ejecuta WebPageTest para identificar los recursos que no se entregan desde una CDN (pero que deberían hacerlo). En la página de resultados, haz clic en el cuadrado sobre "Uso eficaz de la CDN" para ver la lista de recursos que se deben entregar desde una CDN.

Flecha que apunta al botón "Uso eficaz de CDN"
Resultados de WebPageTest

Corregir

Si la CDN no almacena en caché un recurso, verifica que se cumplan las siguientes condiciones:

Escalamiento de recursos de procesamiento

La decisión de escalar los recursos de procesamiento debe tomarse con cuidado. Si bien a menudo es necesario escalar los recursos de procesamiento, hacerlo de forma prematura puede generar complejidad arquitectónica y costos financieros innecesarios.

Diagnosticar

Un tiempo hasta el primer byte (TTFB) alto puede ser un indicio de que un servidor está llegando a su capacidad. Puedes encontrar esta información en la auditoría Reduce los tiempos de respuesta del servidor (TTFB) de Lighthouse.

Para investigar más, usa una herramienta de supervisión para evaluar el uso de la CPU. Si el uso actual o previsto de la CPU supera el 80%, considera aumentar la cantidad de servidores.

Corregir

Agregar un balanceador de cargas permite distribuir el tráfico entre varios servidores. Un balanceador de cargas se ubica frente a un grupo de servidores y enruta el tráfico al servidor adecuado. Los proveedores de servicios en la nube ofrecen sus propios balanceadores de cargas (GCP, AWS, Azure), o bien puedes configurar el tuyo con HAProxy o NGINX. Una vez que se implemente un balanceador de cargas, se pueden agregar servidores adicionales.

Además del balanceo de cargas, la mayoría de los proveedores de servicios en la nube ofrecen el ajuste de escala automático (GCP, AWS, Azure). El ajuste de escala automático funciona junto con el balanceo de cargas, ya que ajusta automáticamente los recursos de procesamiento según la demanda en un momento determinado. Dicho esto, el ajuste de escala automático no es mágico: las instancias nuevas tardan en activarse y requieren una configuración significativa. Debido a la complejidad adicional que implica el ajuste de escala automático, primero se debe considerar una configuración más simple basada en el balanceador de cargas.

Habilitar la compresión

Los recursos basados en texto se deben comprimir con gzip o brotli. Gzip puede reducir el tamaño de transferencia de estos recursos en un ~70%.

Diagnosticar

Usa la auditoría Habilita la compresión de texto de Lighthouse para identificar los recursos que se deben comprimir.

Corregir

Para habilitar la compresión, actualiza la configuración del servidor. Instrucciones:

Optimiza las imágenes y el contenido multimedia

Las imágenes representan la mayor parte del tamaño de los archivos de la mayoría de los sitios web. La optimización de las imágenes puede reducir el tamaño de un sitio de forma rápida y significativa.

Diagnosticar

Lighthouse tiene una variedad de auditorías que marcan posibles optimizaciones de imágenes. Como alternativa, otra estrategia es usar DevTools para identificar los archivos de imagen más grandes, ya que es probable que estas imágenes sean buenas candidatas para la optimización.

Auditorías relevantes de Lighthouse:

Flujo de trabajo de las Herramientas para desarrolladores de Chrome:

Corregir

Si tienes tiempo limitado…

Enfócate en identificar las imágenes grandes y cargadas con frecuencia, y optimizarlas de forma manual con una herramienta como Squoosh. Las imágenes hero suelen ser buenas candidatas para la optimización.

Recuerda:

  • Tamaño: Las imágenes no deben ser más grandes de lo necesario.
  • Compresión: En términos generales, un nivel de calidad de 80-85 tendrá un efecto mínimo en la calidad de la imagen y, al mismo tiempo, generará una reducción del 30% al 40% en el tamaño del archivo.
  • Formato: Usa JPEG para las fotos en lugar de PNG, y MP4 para el contenido animado en lugar de GIF.

Si tienes más tiempo…

Considera configurar una CDN de imágenes si las imágenes representan una parte sustancial de tu sitio. Las CDN de imágenes están diseñadas para entregar y optimizar imágenes, y descargan la entrega de imágenes del servidor de origen. La configuración de una CDN de imágenes es sencilla, pero requiere que se actualicen las URLs de las imágenes existentes para que apunten a la CDN de imágenes.

Material de lectura adicional:

Reduce el uso de JS y CSS

La reducción quita los caracteres innecesarios de JavaScript y CSS.

Diagnosticar

Usa las auditorías de Lighthouse Reduce el uso de CSS y Reduce el uso de JavaScript para identificar los recursos que necesitan reducción.

Corregir

Si tienes tiempo limitado, enfócate en reducir tu código JavaScript. La mayoría de los sitios tienen más JavaScript que CSS, por lo que esto tendrá más impacto.

Supervisar

Las herramientas de supervisión de servidores proporcionan recopilación de datos, paneles y alertas sobre el rendimiento del servidor. Su uso puede ayudar a prevenir y mitigar futuros problemas de rendimiento del servidor.

La configuración de supervisión debe ser lo más simple posible. La recopilación y generación de alertas excesivas tienen sus costos: cuanto mayor sea el alcance o la frecuencia de la recopilación de datos, más costoso será recopilarlos y almacenarlos. La generación excesiva de alertas lleva, inevitablemente, a páginas ignoradas.

Las alertas deben usar métricas que detecten problemas de forma coherente y precisa. El tiempo de respuesta del servidor (latencia) es una métrica que funciona muy bien para esto: detecta una amplia variedad de problemas y se correlaciona directamente con la experiencia del usuario. Las alertas basadas en métricas de nivel inferior, como el uso de la CPU, pueden ser un complemento útil, pero detectarán un subconjunto más pequeño de problemas. Además, las alertas deben basarse en el rendimiento observado en el extremo (en otras palabras, el percentil 95 o 99), en lugar de los promedios. De lo contrario, los promedios pueden ocultar fácilmente los problemas que no afectan a todos los usuarios.

Corregir

Todos los proveedores de servicios en la nube principales ofrecen sus propias herramientas de supervisión (GCP, AWS, Azure). Además, Netdata es una excelente alternativa gratuita y de código abierto. Independientemente de la herramienta que elijas, deberás instalar el agente de supervisión de la herramienta en cada servidor que quieras supervisar. Cuando termines, asegúrate de configurar las alertas.

Instrucciones: