Cómo solucionar problemas de un servidor sobrecargado

Cómo determinar el 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. Evaluar: 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. Supervisar: Usa herramientas automatizadas para evitar problemas futuros.

Evalúa

Cuando el tráfico sobrecarga un servidor, una o más de las siguientes opciones 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 de mayor impacto.

  • CPU: El uso de CPU que supera el 80% de forma constante debe investigarse y corregirse. El rendimiento del servidor a menudo se degrada una vez que el uso de la CPU alcanza entre un 80% y un 90%, y se vuelve más pronunciado a medida que el uso se acerca al 100%. El uso de CPU de entregar una sola solicitud es insignificante, pero hacer esto a la escala que se encuentra durante los aumentos de tráfico a veces puede sobrecargar un servidor. Transferir la entrega a otra infraestructura, reducir las operaciones costosas y limitar la cantidad de solicitudes reducirá el uso de CPU.
  • Red: Durante los períodos de mucho tráfico, la capacidad de procesamiento de la red necesaria para cumplir con las solicitudes de los usuarios puede superar la capacidad. Según el proveedor de hosting, algunos sitios también pueden alcanzar los límites respecto de la transferencia acumulativa de datos. Reducir el tamaño y la cantidad de datos que se transfieren hacia y desde el servidor eliminará este cuello de botella.
  • Memoria: Cuando un sistema no tiene suficiente memoria, los datos se deben descargar al disco para su almacenamiento. El acceso al disco es considerablemente más lento que la memoria, y esto puede ralentizar toda la aplicación. Si la memoria se agota por completo, se pueden generar errores de memoria insuficiente (OOM). Ajustar la asignación de memoria, corregir fugas 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á restringida por el 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 memoria). Si esto no funciona, tal vez debas actualizar los discos.

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

Ejecutar top en el servidor afectado es un buen punto de partida para investigar cuellos de botella. Complementa esto con datos históricos de tu proveedor de hosting o herramientas de supervisión si están disponibles.

Estabilizar

Un servidor sobrecargado puede ocasionar 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 mediante la limitación de la cantidad de solicitudes entrantes. Esto es cada vez más importante a medida que disminuye 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 ascendente, por ejemplo, a través de un balanceador de cargas, un proxy inverso o una CDN.

Instrucciones:

Material de lectura adicional:

Almacenamiento en caché de HTTP

Busca formas de almacenar en caché el contenido de forma más drástica. Si un recurso se puede entregar desde una caché HTTP (ya sea la caché del navegador o una CDN), no es necesario que se solicite desde el 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 un recurso en caché. Auditar y corregir estos encabezados mejorará el almacenamiento en caché.

Aunque los service worker también pueden usarse para el almacenamiento en caché, usan una caché independiente y son un complemento, en lugar de un reemplazo, para el almacenamiento en caché HTTP adecuado. Por este motivo, cuando se administra un servidor sobrecargado, los esfuerzos deben enfocarse en optimizar el almacenamiento en caché HTTP.

Diagnosticar

Ejecuta Lighthouse y consulta la auditoría Publica elementos estáticos con una política de caché eficiente para ver una lista de recursos con un tiempo de actividad (TTL) corto a medio. Para cada recurso de la lista, considera si se debe aumentar el TTL. A modo de lineamiento, considera 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 de segundos adecuada.

Instrucciones:

Degradación elegante

La degradación correcta es la estrategia de reducir temporalmente la funcionalidad para eliminar el exceso de carga de un sistema. Este concepto se puede aplicar de muchas formas diferentes; por ejemplo, mediante la entrega de una página de texto estática en lugar de una aplicación con todas las funciones, la inhabilitación de la búsqueda o la devolución de menos resultados de la búsqueda, o la inhabilitación de funciones costosas o no esenciales. Se debe hacer énfasis en eliminar las funcionalidades que se pueden quitar de forma segura y fácil con un impacto empresarial mínimo.

Mejora

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

La entrega de elementos 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 rápidamente mediante una gran red de servidores que se encuentran cerca de los usuarios. 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 medios.

Configura una CDN

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

Optimizar el uso de CDN

Diagnosticar

Identifica los recursos que no se entregan desde una CDN (pero que deberían hacerlo) ejecutando WebPageTest. 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 debe tomarse con cuidado. Si bien suele ser necesario escalar los recursos de procesamiento, hacerlo antes de tiempo puede generar complejidad arquitectónica y costos financieros innecesarios.

Diagnosticar

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

Para investigar más, usa una herramienta de supervisión a fin de evaluar el uso de la CPU. Si el uso de CPU actual o previsto supera el 80%, considera aumentar tus 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 correspondiente. 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 instalado 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, Azure). El ajuste de escala automático funciona junto con el balanceo de cargas; el ajuste de escala automático aumenta o disminuye la escala de 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 un tiempo en estar en línea y se requiere 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 sencilla basada en un balanceador de cargas.

Habilita 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 aproximadamente un 70%.

Diagnosticar

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

Corregir

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

Optimiza imágenes y contenido multimedia

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

Diagnosticar

Lighthouse cuenta con varias auditorías que marcan posibles optimizaciones de imagen. Otra estrategia es usar las Herramientas para desarrolladores para identificar los archivos de imagen más grandes; estas imágenes probablemente serían buenas candidatas para la optimización.

Auditorías relevantes de Lighthouse:

Flujo de trabajo de las Herramientas para desarrolladores de Chrome:

Corregir

Si tienes un tiempo limitado...

Concéntrate en identificar imágenes grandes y que se cargan con frecuencia, y optimizarlas manualmente con una herramienta como Squoosh. Las hero image suelen ser buenas candidatas para la optimización.

Recuerda:

  • Tamaño: Las imágenes no deben ser más grandes del tamaño necesario.
  • Compresión: En general, un nivel de calidad de 80 a 85 tiene un efecto mínimo en la calidad de la imagen y reduce el tamaño del archivo de un 30 a un 40%.
  • Formato: Usa archivos 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 las imágenes representan una parte considerable de tu sitio. Las CDN de imágenes están diseñadas para entregar y optimizar imágenes, y descargarán la entrega de imágenes del servidor de origen. Configurar una CDN de imágenes es sencillo, pero requiere actualizar las URLs existentes de las imágenes para que apunten a ella.

Material de lectura adicional:

Reduce el uso de JS y CSS

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

Diagnosticar

Utiliza las auditorías de Lighthouse Minify CSS y Minify JavaScript para identificar los recursos que necesitan reducción.

Corregir

Si tienes tiempo limitado, concéntrate en reducir el uso de JavaScript. La mayoría de los sitios tienen más código JavaScript que CSS, por lo que esto tendrá un mayor impacto.

Supervisar

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

La configuración de la 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, llevan a páginas ignoradas.

Las alertas deben usar métricas que detecten problemas de manera coherente y precisa. El tiempo de respuesta del servidor (latencia) es una métrica que es particularmente útil para esto, ya que detecta una gran 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, en los percentiles 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 principales proveedores de servicios en la nube 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, tendrás que instalar el agente de supervisión de la herramienta en cada servidor que desees supervisar. Cuando termines, asegúrate de configurar las alertas.

Instrucciones: