Sitio para todos los que llegan a la vez
· 4 min de lectura
La gente casi nunca llega de uno en uno. Alguien comparte un artículo, varias personas hacen clic en el mismo segundo y cada una abre una página que pide en silencio una docena más al servidor. El 13 de septiembre nos sentamos con los números de ese momento y redimensionamos pagetovid.com para que una oleada de visitantes simplemente se atienda, rápido, siempre.
Una visita son muchas peticiones
Nuestro servicio web funciona en Cloud Run. Dos ajustes deciden cuánto puede atender a la vez: cuántas peticiones gestiona un contenedor al mismo tiempo y cuántos contenedores pueden funcionar en paralelo. Multiplícalos y tienes el techo de toda la web. El nuestro era 4 por 3: doce peticiones en el mismo instante.
Doce parece generoso hasta que cuentas lo que cuesta una visita. Cada página de nuestra web se genera en el servidor, y una página llena de enlaces de navegación carga por adelantado varias de las páginas que hay detrás, para que se abran al instante al hacer clic. Una sola visita se multiplica en 8 a 16 peticiones. Dos o tres personas abriendo una página en el mismo segundo pueden agotar toda la capacidad, y cuando está llena, la plataforma rechaza la siguiente petición al momento en lugar de ponerla en cola.
Queríamos que ningún visitante se topara nunca con ese límite.
Más espacio, con el mismo coste en reposo
Cambiamos tres números, cada uno por un motivo claro:
- la concurrencia de 4 a 20: la palanca que no cuesta nada, porque usa los contenedores que ya están en marcha
- el máximo de contenedores de 3 a 10: suficiente para absorber un pico real
- el tiempo límite de una petición de una hora a dos minutos: nada en la parte web necesita más, porque los renders van en tareas aparte y nuestro punto de acceso MCP se limita a 60 segundos, y una petición atascada nunca debería ocupar un hueco durante una hora
El techo pasó de 12 peticiones simultáneas a 200. Lo que pagas cuando la web está tranquila es el número mínimo de contenedores, y no cambió. Más margen, el mismo coste en reposo.
Un ajuste vive donde la publicación lo ve
Este tipo de ajuste esconde una trampa discreta. Nuestro paso de publicación se los pasa a la plataforma en cada despliegue, así que un valor cambiado a mano en el servicio en marcha vuelve al antiguo con la siguiente versión.
Por eso los números nuevos viven en el propio flujo de publicación, junto al código, revisados como el código y aplicados con cada versión. Un ajuste de capacidad que la publicación no conoce es una prueba, no un arreglo. Desde ese día, cada versión lleva consigo la capacidad real de la web.
Cada cifra de capacidad es una multiplicación
Subir el número de contenedores cambia algo más: la carga sobre la base de datos. Cada contenedor mantiene un pequeño grupo de conexiones abiertas con la base. El tamaño por defecto de ese grupo depende de la máquina: cinco por contenedor en la nuestra. Con tres contenedores eran 15. Con diez serían 50, y nuestra base acepta 25.
Así que fijamos el tamaño del grupo en lugar de dejarlo a una aritmética que nadie hace. Dos conexiones por contenedor, por diez contenedores, son veinte, lo que deja sitio para las tareas de render, la comprobación del esquema que hace cada contenedor al arrancar y una persona que necesite abrir una consola en la base. El límite se fija en el código y no dentro de la cadena de conexión guardada, porque la credencial y el tamaño del grupo son cosas distintas: una es un secreto y la otra una propiedad del programa que la usa. Un valor de configuración aún puede cambiarlo.
Medido en la web en producción
Comprobamos el resultado en el servicio real enviando 40 peticiones exactamente al mismo tiempo. Las 40 recibieron respuesta, con páginas en 180 a 340 milisegundos. Es más del triple del techo anterior de golpe, con margen de sobra.
También dejamos por escrito lo aprendido, junto al código y en nuestras notas del proyecto:
- cada cifra de capacidad es un producto: concurrencia por contenedores es el techo de la web, tamaño del grupo por contenedores es la carga de la base
- cambia un factor y vuelve a calcular cada producto en el que aparece
- en una web donde cada página se genera en el servidor, la precarga de enlaces multiplica el tráfico, y quien añada un menú de enlaces debe saber lo que cuesta
Hay más capítulos sobre la plataforma que hay detrás de los vídeos en el blog.
Míralo en tu propia web
Pega una página y obtén el vídeo narrado del que habla este blog. El primero es gratis.
Sigue leyendo
