Cree una prueba de capacidad de VPS que responda a una pregunta real de planificación
Una prueba de capacidad resulta útil cuando explica qué carga de trabajo puede soportar un servicio en condiciones determinadas. Enviar solicitudes hasta que algo falle produce una cifra, pero esa cifra puede describir una ruta de caché poco realista o un generador de carga saturado. Empiece por la decisión que la prueba debe respaldar y, a partir de ahí, diseñe la carga de trabajo y las mediciones.
La conclusión práctica
Pruebe trabajo representativo en un entorno autorizado, mida conjuntamente las respuestas correctas y las distribuciones de latencia, identifique la capa limitada y conserve las condiciones junto con el resultado.
Defina la decisión antes de construir la prueba
Indique qué está cambiando y qué debe seguir haciendo la aplicación. Una campaña próxima puede aumentar la navegación, mientras que una tarea de importación puede competir con el tráfico normal de API. Un cambio de recursos puede tener como objetivo reducir los tiempos de respuesta durante un pico existente. Nombre el recorrido importante y su comportamiento aceptable. Evite empezar por un número de solicitudes arbitrario que no guarde relación con cómo las personas o los procesos en segundo plano utilizan el servicio.
Registre la versión actual de la aplicación, el tamaño de la base de datos, la región, los recursos de alojamiento y la configuración relevante. Incluya el almacenamiento en caché, los límites de los procesos de trabajo y las dependencias externas. Así, el resultado se convierte en algo que otro responsable de mantenimiento puede repetir. Si una ejecución posterior cambia varios de estos elementos a la vez, etiquétela como un escenario distinto en lugar de presentarla como prueba de que un CPU adicional lo resolvió todo. Mantenga las credenciales de prueba separadas de las cuentas reales de clientes.
Utilice un entorno de pruebas u otro entorno controlado con permiso explícito y una ventana adecuada. Coordine con el equipo cuando la prueba pueda afectar a infraestructura compartida o a los límites del servicio. Sustituya las acciones externas de pago, correo electrónico y otros terceros por integraciones de prueba adecuadas, salvo que se haya acordado su participación. Un ejercicio de capacidad no debe generar compras reales, enviar un gran lote de mensajes ni convertirse en una avalancha de tráfico no anunciada contra otro servicio.
Modele el trabajo de la aplicación, no un titular atractivo
Elija una combinación realista de solicitudes y estados de visitante. Las páginas públicas en caché, las API autenticadas, las cargas de archivos y las búsquedas costosas pueden tener costes muy distintos. Incluya pausas adecuadas o un patrón de llegada que se ajuste a la pregunta de planificación. Una prueba que solicita repetidamente la misma respuesta pequeña en caché puede ayudar a comprobar esa ruta, pero no determina la capacidad de las páginas de cuenta ni de las escrituras en la base de datos. Explique esa limitación junto con el resultado.
| Escenario | Qué responde | Qué no determina |
|---|---|---|
| Página pública en caché | Comportamiento de una ruta de respuesta reutilizable | Capacidad de la aplicación personalizada |
| Recorrido de API con sesión iniciada | El trabajo seleccionado de la aplicación y la base de datos | Todos los endpoints o patrones de cliente posibles |
| Tarea programada más solicitudes normales | Contención durante esa superposición conocida | Tareas futuras con datos distintos |
| Llegadas que aumentan gradualmente | Dónde empiezan a aumentar la latencia y los errores | Un máximo universal para la gama de alojamiento |
Rellene la prueba con distribuciones de datos representativas. Una lista de productos con unas pocas filas puede ejercer un comportamiento de consulta distinto al de una con un historial extenso. Utilice datos sintéticos o debidamente protegidos y confirme que los procedimientos de restablecimiento y limpieza funcionan antes de la ejecución principal. Vigile la CPU, la red y la planificación del generador de carga, además de la aplicación. De lo contrario, un cuello de botella del generador puede hacer que un servidor parezca estable simplemente porque el trabajo previsto nunca llegó.
Mida las operaciones completadas y defina cuándo detener la prueba
Siga juntas la tasa de operaciones completadas correctamente, los fallos y las distribuciones de latencia. Una media puede ocultar respuestas inusualmente lentas, mientras que una tasa de solicitudes alta puede incluir respuestas que fallan en el recorrido del usuario. Compruebe el contenido de las respuestas o los resultados de la aplicación cuando proceda, en lugar de tratar cada respuesta HTTP como un éxito. Separe el tiempo dedicado a conectar del tiempo de espera de la aplicación y del tiempo de transferencia cuando las herramientas lo permitan. Compare estas observaciones con las mediciones del servidor y de la base de datos del mismo periodo.
Defina las condiciones de parada antes de ejecutar la prueba. Pueden incluir errores sostenidos, latencia inaceptable, presión excesiva sobre los recursos o una señal de que otro sistema está resultando afectado. Elija valores adecuados a la aplicación y al entorno reales; no existe un umbral universal que demuestre que todos los servicios están en buen estado. Los umbrales automatizados pueden ayudar a evaluar una ejecución, pero alguien debe seguir siendo responsable de la prueba, de sus efectos y de la decisión de detenerse.
Aumente el trabajo por etapas para poder observar el cambio en lugar de saltar inmediatamente a un extremo. Mantenga un periodo estable el tiempo suficiente para ver el comportamiento relevante para la carga de trabajo, incluidos los efectos conocidos de cola o caché. Registre cuándo empieza la prueba y cuándo cambia cada etapa. Si la latencia aumenta mientras la CPU sigue baja, investigue la espera, la contención y las dependencias antes de concluir que el plan necesita más núcleos.
Convierta el resultado en un siguiente paso controlado
- Guarde la definición de la carga de trabajo, los supuestos sobre los datos y las versiones del software.
- Informe juntos el número de operaciones correctas por segundo, la tasa de errores y los percentiles de latencia.
- Identifique la capa probablemente limitada y las pruebas que lo respaldan.
- Cambie un ajuste o recurso relevante y repita el mismo escenario.
- Documente el margen restante y los límites de la conclusión.
Por ejemplo, una API puede resistir bien las lecturas habituales pero acumular una cola larga cuando una exportación programada se solapa con ellas. La respuesta útil puede ser reprogramar o rediseñar la exportación, reducir la duración de las transacciones o ajustar el recurso adecuado. Una configuración de alojamiento mayor es una posible intervención, no el único resultado. Vuelva a comprobar el recorrido completo de la aplicación tras un cambio para que unas respuestas más rápidas no oculten tareas incorrectas o no realizadas.
Mantenga los resultados ligados a sus condiciones al elegir un VPS. Un núcleo virtual, la asignación de memoria y el puerto de red describen recursos; no garantizan un número fijo de visitantes o solicitudes para cada aplicación. Repita la prueba tras cambios significativos en el código, los datos o la combinación de tráfico. La planificación de capacidad resulta más fiable cuando es una comparación repetida con supuestos registrados, en lugar de una única cifra impresionante desvinculada del sistema que la produjo.
