Cómo preparamos un sitio de noticias para un pico de tráfico.
El negocio de un sitio de noticias son los picos. Este es el método que usamos para dejarlo listo: leer los logs correctos, saber dónde está el techo, comprobar cada capa antes de gastar y hacer la aritmética.
En este artículo 4 secciones
- El tráfico deja al descubierto los techos; la configuración fija los techos. Prepararse para un pico es encontrarlos antes de que lo haga la audiencia.
- Primero, confirme qué log lleva realmente el tráfico del sitio. El log por defecto del servidor puede contener una pequeña parte mientras el log del propio vhost del sitio contiene el resto.
- Compruebe cada capa antes de gastar. La base de datos suele estar ociosa y rápida mientras el trabajo hace cola una capa más arriba.
- Después, la aritmética: workers dividido por segundos por petición es su techo real en peticiones por segundo. Dimensione el pool para el pico que realmente va a alcanzar, más margen.
El negocio de un sitio de noticias son los picos: cuando salta la noticia, la audiencia llega de golpe. Prepararse para eso rara vez es una cuestión de hardware. Es una cuestión de configuración: el número de workers, los timeouts, los logs, la caché. Así es como preparamos uno.
Lea primero el log correcto
La primera disciplina es contar bien. En un servidor web típico, el log por defecto y el log del propio vhost del sitio son ficheros distintos, y el log por defecto puede contener solo una pequeña parte del tráfico. Dimensione cualquier cosa a partir del log equivocado y la dimensionará para la carga equivocada.
Sepa dónde está el techo
Bajo carga, los tiempos de las peticiones le dicen dónde está el límite. La lentitud orgánica se dispersa: algunas peticiones algo lentas, otras muy lentas. Las peticiones lentas que se agrupan exactamente en el timeout del gateway significan que la capa detrás del gateway se está quedando sin workers dentro de su presupuesto. Esa es la firma de la saturación, y señala directamente al parámetro que hay que dimensionar.
Compruebe cada capa antes de gastar
Antes de que nadie compre RAM o amplíe la capa de datos, compruébela. Una base de datos ociosa y rápida, sin consultas lentas, que responde a todo en el momento en que se le pregunta, no es la capa que hay que dimensionar. La capa que hay que dimensionar es aquella cuyos workers están todos ocupados. Ese patrón tiene su propio artículo en dimensione hacia abajo, no hacia arriba.
Su techo es aritmética
WORKERS
SEG / PETICIÓN
PET / SEG
La preparación es dimensionar, no comprar: el pool de workers calculado a partir del pico que un sitio de noticias va a alcanzar realmente, más margen, dentro de un presupuesto de memoria por worker medido. Después, una capa de caché que sirve contenido antiguo cuando el backend se ralentiza, de modo que un backend saturado se degrada a páginas ligeramente desactualizadas en lugar de a páginas de error. La plataforma absorbe el pico.
“El tráfico encuentra el techo que usted fija. Fíjelo a propósito.”
Respuestas directas
¿Por qué un sitio devuelve errores 502 con mucho tráfico?+
Normalmente, la capa detrás del gateway se ha quedado sin workers y el gateway se rinde en su timeout. La firma son peticiones lentas clavadas exactamente en un número. Cuente primero los errores en el log del vhost correcto, porque el log por defecto puede contener solo una fracción de su tráfico.
¿Cuántos workers debería tener mi servidor de aplicaciones?+
Calcúlelo: workers dividido por la media de segundos por petición es su techo en peticiones por segundo. Dimensione para el pico que realmente va a alcanzar, más margen, dentro de un presupuesto de memoria por worker medido, en lugar de fiarse del valor por defecto del paquete.
¿Es la base de datos el cuello de botella cuando el tráfico se dispara?+
Verifíquelo antes de gastar. Compruebe si está ociosa u ocupada y si existen consultas lentas. A menudo la base de datos está ociosa y rápida, y el trabajo hace cola una capa más arriba. Compruebe cada capa primero.
¿Cómo preparo un sitio para un pico de tráfico?+
Haga la aritmética de los workers contra su pico realista, confirme qué logs llevan realmente su tráfico, haga pruebas de carga hasta el techo calculado y ponga delante una caché que sirva contenido antiguo ante errores, de modo que un backend lento sirva páginas antiguas en lugar de errores.
¿Más tráfico no exige, sin más, más servidores?+
Con el tiempo, pero casi nunca en primer lugar. Primero use la capacidad que su configuración está reteniendo: pools dimensionados correctamente, timeouts razonables, una caché que absorba la avalancha de lecturas. El hardware comprado para cubrir un parámetro de configuración es el cambio de configuración más caro que existe.
¿Espera pronto su mejor día?
Lanzamiento, prensa, pico de temporada: tráiganos la fecha. Haremos la aritmética de los workers, leeremos los logs correctos y convertiremos el pico en una gráfica más.
Hable con un ingenieroHa llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero