Una fecha de lanzamiento es un plan de tráfico, no un hecho de tráfico. Un título nuevo, un bote que se acumula, un partido de eliminatoria o una campaña cambian cuántos jugadores llegan y a qué velocidad; y si la plataforma absorbe ese cambio es una afirmación que alguien tiene que probar en lugar de dar por supuesta.
Una prueba de carga responde con honestidad a una pregunta acotada: ¿puede este sistema, en esta configuración, atender esta mezcla de trabajo a este ritmo sin incumplir sus propios objetivos? Casi todo lo demás que se dice sobre las pruebas de carga —que una plataforma «escala», que «aguantará el día del lanzamiento»— es una predicción sobre un tráfico que nadie ha medido todavía.
El lanzamiento es la propia punta de tráfico
La lista de coordinación de lanzamientos de Google es un buen punto de partida porque se escribió para ejecutarse antes de una fecha, no después de un incidente. Pide al equipo de lanzamiento «estimaciones de tráfico HTTP y ancho de banda, la “punta” del lanzamiento y la mezcla de tráfico», una «prueba de carga, prueba de extremo a extremo, capacidad por centro de datos con latencia máxima», el «impacto sobre los demás servicios que más nos importan» y la «degradación gradual y cómo evitar saturar por accidente servicios de terceros».
Esa lista es general para servicios web y es anterior a buena parte del instrumental actual del sector. Su forma sigue encajando en una plataforma de juego, porque un lanzamiento es un escalón y no una pendiente. En el momento en que un título sale en vivo, los jugadores llegan juntos, y cada llegada no es una sola petición. El inicio de sesión, la lectura del vestíbulo, la consulta del saldo, la apuesta, el resultado, la secuencia de apuntes en la billetera y la lectura del historial son trabajos distintos que llegan multiplicados por la misma multitud.
Escriba el modelo de carga antes de escribir el guion
Una prueba comparativa contra un solo punto de acceso mide un punto de acceso. No dice nada de la plataforma. El primer artefacto útil de un programa de capacidad es, por tanto, un inventario del trabajo que la plataforma hace de verdad, con el coste y los efectos secundarios de cada entrada:
| Trabajo | Qué debe modelar la prueba | Qué escribe |
|---|---|---|
| Inicio de sesión y autenticación | Ráfagas de acceso en el momento del anuncio, incluidas las repeticiones que provoca una respuesta lenta | Registros de sesión y eventos de autenticación |
| Lecturas de vestíbulo, catálogo y ficha de juego | Sobre todo lecturas, baratas una a una, dominantes en volumen | Nada |
| Ciclo de ronda | Aceptación de la apuesta, generación del resultado y los apuntes en la billetera que liquidan la ronda | Apuntes del libro mayor e historial de rondas |
| Contribución y acumulación de botes | Un contador compartido que toca cada ronda contribuyente | Estado de acumulación y sus registros justificativos |
| Evaluación y concesión de bonos | Reglas con muchas lecturas y escrituras ocasionales que crean pasivo | Registros de bonos y pasivo pendiente |
| Pagos | Inicio del depósito, retornos del proveedor y retiradas, cada uno con su propia latencia externa | Registros de pago y de billetera |
| Consultas de back-office e informes | Largas, costosas y a menudo ejecutadas por personal en horario laboral | Nada, pero consumen los mismos recursos |
| Flujos de eventos y analítica | Continuos, asíncronos y fáciles de olvidar al dimensionar | Desplazamientos del flujo y reporting derivado |
Dos decisiones de ese modelo determinan qué puede concluir la prueba. La primera es la mezcla: una ejecución compuesta sobre todo de lecturas de vestíbulo pasará con holgura sin decir nada del camino de la ronda. La segunda es si la carga se modela como una población fija de usuarios o como una tasa fija de llegada. La distinción merece leerse en la documentación de k6 sobre modelos abiertos y cerrados, porque ambos se comportan de forma distinta en cuanto el sistema se ralentiza: uno aplica contrapresión esperando, el otro sigue llegando.
Un recuento de peticiones no es un modelo de capacidad
Es tentador expresar la capacidad como peticiones por segundo y comparar esa cifra con una estimación de lanzamiento. El capítulo de SRE sobre cómo gestionar la sobrecarga explica por qué esa comparación engaña: «Distintas consultas pueden tener necesidades de recursos enormemente distintas», y modelar la capacidad como «consultas por segundo» o como rasgos estáticos de la petición «a menudo da una métrica pobre», porque las proporciones entre peticiones cambian a medida que cambia el producto. La recomendación del capítulo es medir la capacidad en recursos disponibles —la CPU primero, en la mayoría de los casos— y definir límites por cliente para que el exceso de uno no deje sin recursos a los demás.
Para una plataforma de juego, la versión práctica es que una ronda liquidada que toca el libro mayor varias veces no es intercambiable con una lectura de vestíbulo. Si el modelo de carga no lleva un coste por unidad de trabajo, la cifra de punta que se derive de él es un número sin unidades.
Pruebe en un entorno que pueda fallar igual
Una prueba de carga ejecutada contra un entorno infradimensionado produce una cifra confiada sobre el sistema equivocado. La paridad importa allí donde se decide si una consulta es rápida: el volumen del conjunto de datos y el tamaño de los índices, las estadísticas de las tablas, la configuración y el estado de los indicadores de funcionalidad bajo prueba, la temperatura de la caché y si los socios de integración son accesibles con una latencia realista. Un conjunto de datos restaurado y con forma de producción encontrará la consulta lenta que una muestra de unos miles de filas nunca encontrará. La guía de requisitos de entornos no productivos cubre qué más debe separar ese entorno antes de poder usarse para esto.
Seis tipos de prueba, seis modos de fallo distintos
La página de Grafana sobre tipos de prueba de carga ordena el trabajo en pruebas de humo, de carga media, de estrés, de resistencia prolongada, de pico y de punto de ruptura, y aporta dos ideas que conviene llevarse a cualquier programa de capacidad: «ningún tipo de prueba por sí solo elimina todos los riesgos», y las categorías son relativas: «una prueba de estrés para una aplicación es una prueba de carga media para otra».
| Tipo | La pregunta que responde en una plataforma | Qué conservar |
|---|---|---|
| Humo | ¿El guion sigue recorriendo el camino real tras la última entrega? | La versión del guion y un resultado de referencia |
| Carga media | ¿Mantiene la plataforma sus objetivos con la mezcla esperada? | Latencia y tasa de error en el ritmo modelado |
| Estrés | ¿Qué ocurre por encima de la punta esperada y qué se degrada primero? | El punto de la primera degradación y su forma |
| Resistencia prolongada | ¿Aguanta la plataforma horas y no minutos? | La tendencia de recursos durante la ejecución, no solo el final |
| Pico | ¿Sobrevive una llegada súbita y breve sin cascada? | El tiempo de recuperación y si algo quedó atascado |
| Punto de ruptura | ¿Dónde está el límite y el fallo es ordenado? | El recurso limitante y el comportamiento de rechazo |
La ventana de resistencia prolongada es donde aparece la acumulación
Una prueba de una hora con carga media ejercita los caminos; una prueba de resistencia prolongada ejercita la aritmética de la plataforma manteniendo estado. Los fallos que encuentra son lentos: un grupo de conexiones que pierde un descriptor por ciclo, una tabla de sesiones que crece sin una tarea de retención, una caché que nunca expulsa, una cola que se vacía durante el día y nunca de noche, una acumulación que se desvía porque una tarea de conciliación no se ha ejecutado, y un volumen de registros que llena un disco tras superar un umbral que nadie modeló. La propia descripción de Grafana de una prueba de resistencia prolongada es «la fiabilidad y el rendimiento de su sistema durante periodos extensos», con una duración medida en horas y no en minutos.
Dos reglas prácticas hacen que una prueba de resistencia prolongada merezca su tiempo de calendario: ejecutarla lo bastante larga como para cruzar al menos una ventana programada de mantenimiento o de proceso por lotes, y observar los recursos a lo largo del tiempo en lugar de leer el resumen del final.
La carga sintética escribe registros financieros reales
Una prueba de carga contra una plataforma de juego no reenvía una página estática. Cada ronda simulada crea apuntes en el libro mayor, cada bono simulado crea pasivo y cada depósito simulado crea un registro de pago. Esos registros acaban en las mismas tablas a partir de las cuales informa el negocio y, si la prueba no se identifica, después serán indistinguibles de la actividad real.
Decida antes de la ejecución cómo se marca el tráfico sintético, qué cuentas o inquilinos utiliza, si queda excluido de la conciliación y cuándo se elimina; y conserve el registro de esa decisión junto con la ejecución. La guía de requisitos de conciliación de la billetera describe los controles que esas exclusiones deben respetar, y la guía de registro de seguridad y evidencia de auditoría describe dónde corresponde el registro de una prueba deliberada.
Su punta también es la punta de sus proveedores
Una plataforma bajo carga empuja esa carga hacia fuera. Los proveedores de pago limitan la tasa, los proveedores de identidad aplican sus propios umbrales y los puntos de acceso de billetera de los proveedores de juego tienen límites propios. La línea de la lista sobre evitar saturar por accidente servicios de terceros avisa exactamente de esto: su punta se convierte en la de ellos, y su degradación vuelve como sus tiempos de espera agotados.
Confirme con cada socio los límites publicados, modele en el entorno su latencia realista y sus errores, y pruebe cómo se comporta su plataforma cuando están lentos en lugar de ausentes. Una política de reintentos agresiva que es inofensiva con volumen normal es la forma en que una dependencia lenta se convierte en una cola que satura todo lo que tiene detrás.
Fije la condición de aprobado antes de pulsar inicio
La lista pide «capacidad por centro de datos con latencia máxima», y la matización es lo importante: una cifra de capacidad sin un límite de latencia describe un sistema que atendió peticiones, no uno que las atendió de forma útil.
Escriba los umbrales primero —el percentil que importa, la tasa de error aceptable, la mezcla que debe usar la ejecución y el techo de recursos— y deje que la ejecución produzca un aprobado o un suspenso frente a ellos. Una conclusión elegida después de leer los resultados es una opinión con un gráfico adjunto. Cuando el objetivo es un objetivo de nivel de servicio para los jugadores, se aplica la misma disciplina que en cualquier otro caso: la cifra es aquello frente a lo que se falla.
Rechace carga a propósito y demuestre que puede
Bajo sobrecarga, el comportamiento deseable no es aceptarlo todo y colapsar. Es seguir atendiendo el tráfico que se puede procesar y rechazar el resto con claridad. El RFC 6585 define la forma de ese rechazo: el código de estado 429 «indica que el usuario ha enviado demasiadas peticiones en un periodo de tiempo dado (“limitación de tasa”)», la respuesta «DEBERÍA incluir detalles que expliquen la condición y PUEDE incluir una cabecera Retry-After», y una respuesta 429 «NO DEBE ser almacenada por una caché». El capítulo de SRE sobre cómo gestionar la sobrecarga plantea lo mismo desde el lado del servicio: una tarea dimensionada para un ritmo debería «seguir atendiendo tráfico a ese ritmo sin un impacto significativo en la latencia, con independencia de cuánto tráfico excesivo se le lance», no debe caerse, y eso debería sostenerse «en algún punto por encima del doble o incluso diez veces lo que la tarea está dimensionada para procesar».
Así que la prueba de estrés tiene un segundo entregable más allá del límite: la evidencia de que el rechazo es ordenado. Supere la capacidad a propósito y compruebe si quienes llaman reciben una respuesta clara y reintentable, o si reciben tiempos de espera agotados mientras las colas se llenan.
Conserve un registro que sobreviva a la entrega
Una ejecución de capacidad que no deja ningún artefacto es indistinguible de una que se omitió. El registro que merece conservarse es corto: el guion y la versión del modelo de carga, el conjunto de datos y cómo se produjo, la topología y los tamaños de instancia, la configuración y el estado de los indicadores de funcionalidad, el perfil de carga, los resultados en bruto, los umbrales, cada excepción con su responsable, quién leyó el resultado y qué se decidió, y la fecha.
Otras dos condiciones pertenecen a ese registro y no a la memoria de alguien. La primera: una prueba contra capacidad compartida o de producción necesita una ventana declarada, un responsable con nombre y una condición de parada definida; una prueba de carga que empieza a afectar a jugadores reales ha dejado de ser una prueba y se ha convertido en el incidente que pretendía evitar. La segunda: si se espera que la ejecución produzca una punta, la guía del plan de respuesta a incidentes es el documento que ya debería indicar quién vigila y quién puede detenerla.
Deténgase en lo que la prueba demuestra
Una ejecución aprobada demuestra que esta compilación, en este entorno, atendió ese modelo de carga en esa fecha y a ese ritmo. No demuestra que la plataforma sea correcta, ni que una población real se comporte como el modelo, ni que un proveedor vaya a respetar sus propios límites, ni que el resultado sobreviva a la siguiente entrega. La capacidad es una tendencia, no una insignia: un cambio en el camino de la ronda, en el volumen de datos o en la topología invalida el último resultado, y la cifra útil es la que lleva una fecha y una compilación al lado.
Por eso también una prueba de carga pertenece a un calendario y no solo a una lista de lanzamiento. La guía de observabilidad del RGS cubre el lado en tiempo de ejecución de la misma pregunta —qué registra la plataforma sobre sí misma mientras atiende— y ambas cosas juntas son lo que convierte una fecha de lanzamiento en un evento vigilado. El trabajo de desarrollo de plataformas es donde se sitúa el lado de capacidad de ese proceso de entrega.
Preguntas que hacen los operadores
¿Cuánto debería durar una prueba de resistencia prolongada?
Lo suficiente para cruzar al menos una ventana programada de proceso por lotes o mantenimiento, lo que en la práctica significa horas y no minutos. La duración no es resistencia por sí misma: sirve para dejar que fugas, crecimiento y desviaciones se acumulen hasta un tamaño visible.
¿Puede ejecutarse alguna vez una prueba de carga contra producción?
Sí, pero es un ejercicio distinto con reglas distintas: ventana declarada, responsable con nombre, condición de parada definida y una decisión sobre los registros sintéticos que crea. Una prueba de carga que degrada el servicio en vivo es un incidente. Cuando el objetivo es medir la plataforma y no el cambio, probar en un entorno con forma de producción es la decisión más barata.
¿Una prueba de carga aprobada demuestra que la plataforma sobrevivirá al día del lanzamiento?
No. Demuestra que una carga modelada fue atendida por una compilación concreta en un entorno concreto en una fecha concreta. Una población real de jugadores decide su propia mezcla, los terceros imponen sus propios límites y la siguiente entrega puede cambiar el coste del trabajo.
