Cómo solucionar problemas de un servidor sobrecargado

Descubre cómo determinar la existencia de cuellos de botella en un servidor, corregir la situación rápidamente, mejorar el rendimiento del servidor y prevenir regresiones.

Katie Hempenius
Katie Hempenius

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. Mejorar: 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 eficaces.

  • CPU: Se debe investigar y corregir el uso de CPU que supere el 80% de forma constante. El rendimiento del servidor suele disminuir una vez que el uso de CPU alcanza entre el 80% y el 90%, y se vuelve más pronunciado a medida que el uso se acerca al 100%. El uso de CPU para entregar una sola solicitud es insignificante, pero hacerlo a la escala que se produce durante los aumentos repentinos de tráfico a veces puede sobrecargar un servidor. Si descargas la entrega a otra infraestructura, reduces las operaciones costosas y limitas la cantidad de solicitudes, disminuirá el uso de CPU.
  • Red: Durante los períodos de tráfico alto, la capacidad de procesamiento de la red necesaria para completar las solicitudes de los usuarios puede superar la capacidad. Algunos sitios, según el proveedor de hosting, también pueden alcanzar límites en cuanto a la transferencia de datos acumulativa. Si reduces el tamaño y la cantidad de datos transferidos hacia y desde el servidor, se quitará este cuello de botella.
  • Memoria: Cuando un sistema no tiene suficiente memoria, los datos se deben descargar en el disco para su almacenamiento. El acceso al disco es mucho más lento que el acceso a la memoria, lo que puede ralentizar toda la 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 eliminar 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 disco en sí. Si la E/S de disco es un cuello de botella, aumentar la cantidad de datos almacenados en caché puede aliviar este problema (a costa de un mayor uso de memoria). Si esto no funciona, es posible que debas actualizar tus 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án disponibles, complementa estos datos con los datos históricos de tu proveedor de hosting o de las 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

La limitación 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: cuando 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 la limitación de frecuencia en algún punto 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 contenido en caché de manera 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. Auditar y corregir estos encabezados mejorará el almacenamiento en caché.

Aunque los service workers también se pueden usar para el almacenamiento en caché, utilizan una caché independiente y son un complemento, en lugar de un reemplazo, para el almacenamiento en caché HTTP adecuado. Por este motivo, cuando se maneja un servidor sobrecargado, los esfuerzos deben centrarse en optimizar el almacenamiento en caché de HTTP.

Realiza diagnósticos

Ejecuta Lighthouse y consulta la auditoría Publica recursos estáticos con una política de caché eficiente para ver una lista de recursos con un tiempo de actividad (TTL) de corto a mediano. Para cada recurso de la lista, considera si se debe aumentar el TTL. A modo de lineamiento general, considera lo siguiente:

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

Corregir

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

Instrucciones:

Degradación elegante

La degradación elegante es la estrategia de reducir temporalmente la funcionalidad para quitar 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ática 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 contenidos (CDN), lo que reduce la carga.

La función principal de una CDN es entregar contenido a los usuarios con rapidez a través de una gran red de servidores ubicados cerca de ellos. Sin embargo, la mayoría de las CDN también ofrecen funciones adicionales relacionadas con el rendimiento, como la compresión, el balanceo de cargas y la 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 establecer (aproximadamente 30 minutos) y consiste en actualizar los registros DNS para que apunten a la CDN.

Optimiza el uso de la CDN

Realiza diagnósticos

Ejecuta WebPageTest para identificar los recursos que no se entregan desde una CDN (pero que deberían). En la página de resultados, haz clic en el cuadrado que se encuentra 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 la 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 se debe tomar con cuidado. Aunque a menudo es necesario escalar los recursos de procesamiento, hacerlo de forma prematura puede generar una complejidad arquitectónica y costos financieros innecesarios.

Realiza diagnósticos

Un valor alto de Time to First Byte (TTFB) puede ser un indicio de que un servidor está llegando al límite de 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 a fondo, usa una herramienta de supervisión para evaluar el uso de CPU. Si el uso de CPU actual o previsto supera el 80%, deberías considerar 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 puedes configurar el tuyo con HAProxy o NGINX. Una vez que se implementa 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 ajuste de escala automático (GCP, AWS y Azure). El ajuste de escala automático funciona junto con el balanceo de cargas: el ajuste de escala automático aumenta y disminuye 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 conectarse 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% aproximadamente.

Realiza diagnósticos

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

Corregir

Actualiza la configuración del servidor para habilitar la compresión. Instrucciones:

Optimiza las imágenes y el contenido multimedia

Las imágenes constituyen la mayor parte del tamaño de archivo de la mayoría de los sitios web. Optimizar las imágenes puede reducir de forma rápida y significativa el tamaño de un sitio.

Realiza diagnósticos

Lighthouse tiene una variedad de auditorías que marcan posibles optimizaciones de imágenes. Como alternativa, otra estrategia es usar las Herramientas para desarrolladores 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 de Lighthouse pertinentes:

Flujo de trabajo de las Herramientas para desarrolladores de Chrome:

Corregir

Si tienes poco tiempo…

Enfoca tu tiempo en identificar imágenes grandes y que se cargan con frecuencia, y optimízalas 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 entre 80 y 85 tendrá un efecto mínimo en la calidad de la imagen, mientras que reducirá el tamaño del archivo entre un 30% y un 40%.
  • Formato: Usa JPEG para las fotos en lugar de PNG; usa MP4 para el contenido animado en lugar de GIF.

Si tienes más tiempo…

Considera configurar una CDN de imágenes si estas constituyen una parte sustancial de tu sitio. Las CDN de imágenes están diseñadas para publicar y optimizar imágenes, y descargarán la publicación de imágenes del servidor de origen. Configurar una CDN de imágenes es sencillo, pero requiere actualizar las URLs de las imágenes existentes para que apunten a la CDN de imágenes.

Material de lectura adicional:

Minimiza JS y CSS

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

Realiza diagnósticos

Usa las auditorías Minimiza CSS y Minimiza JavaScript de Lighthouse para identificar los recursos que se deben reducir.

Corregir

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

Supervisar

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

La configuración de supervisión debe ser lo más sencilla posible. La recopilación de datos y las 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; las alertas excesivas inevitablemente conducen 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 particularmente 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 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 la cola (en otras palabras, los percentiles 95 o 99), en lugar de los promedios. De lo contrario, los promedios pueden ocultar fácilmente problemas que no afectan a todos los usuarios.

Corregir

Todos los principales proveedores de servicios en la nube ofrecen sus propias herramientas de supervisión (GCP, AWS y 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: