Pruebas de carga de una web antes del lanzamiento
Una prueba de carga responde a una pregunta concreta: cuántos visitantes aguanta la web en el servidor elegido y qué falla primero. Se hace en su propio servidor y solo en él: el generador de carga es una máquina aparte, el proveedor está avisado y los servicios externos se sustituyen por stubs. Veamos qué cifras mirar, con qué programas obtenerlas y cómo elegir plan a partir de ellas.
Una web que se abre rápido en el equipo del desarrollador puede dejar de responder cuando llegan cien personas a la vez: se agotan los procesos de PHP, las conexiones a la base de datos o la memoria. Descubrirlo el día de una campaña publicitaria sale más caro que una semana antes. La prueba de carga reproduce un flujo de visitantes en su servidor y muestra dónde está el límite y cuánto margen queda hasta él.
Qué medir
El resultado de una prueba no es una sola cifra, sino un conjunto de indicadores que se analizan juntos:
- RPS (peticiones por segundo): cuántas peticiones procesa el servidor. Por sí solo, el RPS dice poco: un servidor puede atender mil peticiones por segundo y tardar cinco segundos en cada respuesta.
- Tiempo de respuesta por percentiles: p95 significa que el 95 % de las peticiones se completaron en ese tiempo; p99, el 99 %. La media oculta las respuestas lentas: si 90 peticiones tardan 100 ms y 10 tardan 3 segundos, una media de unos 400 ms parece aceptable, aunque uno de cada diez visitantes espera tres segundos.
- Tasa de errores: respuestas 5xx, conexiones cortadas y tiempos de espera agotados. Bajo carga, los errores suelen aparecer antes de que el tiempo de respuesta crezca de forma visible.
- Recursos del servidor: uso del procesador, memoria libre y swap, espera de disco (iowait) y número de conexiones a la base de datos. Estos datos se recogen en el propio servidor durante la prueba; si no, no se sabe qué ha frenado la web.
El objetivo se fija de antemano y en esas mismas unidades, por ejemplo: «con 50 peticiones por segundo, el p95 de la portada y del catálogo por debajo de 500 ms y menos de un 1 % de errores». Sin un objetivo, la prueba se convierte en un montón de gráficas con las que no se puede decidir nada.
Tipos de pruebas
- Prueba de humo: unos pocos usuarios virtuales durante un minuto. Comprueba que el escenario está bien escrito y da el tiempo de respuesta de referencia sin carga.
- Prueba de carga: el pico de tráfico esperado durante 15–30 minutos. Responde a si el servidor soporta la carga prevista.
- Prueba de estrés: la carga se sube por escalones hasta que crecen los errores o el tiempo de respuesta. Muestra el límite y cómo se comporta la web al superarlo: si devuelve un error rápido o se queda colgada.
- Prueba de resistencia: carga moderada durante varias horas. Detecta fugas de memoria, logs y discos que se llenan y conexiones que se acumulan.
El escenario debe parecerse a los visitantes reales: una mezcla de páginas (portada, catálogo, ficha de producto, búsqueda), pausas entre acciones y una parte de usuarios con sesión iniciada o con carrito. Una prueba que pide mil veces por segundo la misma página en caché mide la caché, no la web.
Herramientas
Los cuatro programas siguientes son gratuitos y se ejecutan desde la línea de comandos. Los dos primeros sirven para escenarios con varias páginas; los dos últimos, para comprobar rápido una sola dirección.
- k6: los escenarios se escriben en JavaScript y el resultado se muestra directamente con percentiles. En el escenario se definen umbrales: según la documentación de k6, las condiciones
http_req_failed: ['rate<0.01']yhttp_req_duration: ['p(95)<200']se comprueban al final de la prueba y, si no se cumplen, k6 termina con un código de salida distinto de cero. Por eso es fácil integrar k6 en CI: una compilación que vuelva más lenta la web no pasará. - Apache JMeter: los escenarios se montan en una interfaz gráfica, con formularios, autenticación, análisis de respuestas y datos desde CSV. La prueba en sí se recomienda lanzarla en modo de línea de comandos, con
jmeter -n -t test.jmx -l test.jtl: el modo gráfico consume recursos del generador y distorsiona el resultado. - wrk: un generador multihilo que desde una sola máquina crea mucha carga sobre una dirección. Ejemplo:
wrk -t4 -c100 -d60s --latency https://example.com/, es decir, 4 hilos, 100 conexiones, un minuto y la distribución de latencias. Los escenarios complejos se escriben en Lua. - ab (ApacheBench): la opción más sencilla, a menudo ya instalada junto con Apache. Su documentación advierte de que ab no implementa HTTP/1.x por completo y, con carga alta, puede acabar midiendo su propia velocidad en lugar de la del servidor. El keep-alive está desactivado por defecto y se activa con la opción
-k. Sirve para una comprobación rápida, no para decidir un plan.
Cómo hacer la prueba sin perjudicar a nadie
Una prueba de carga genera el mismo flujo de peticiones que una avalancha de visitantes, así que solo puede hacerse en un servidor que usted administra y respetando las normas de la plataforma en la que está alojado.
- Solo su servidor y su dominio. Cargar webs o API ajenas sin el consentimiento por escrito de su propietario es inadmisible, aunque sea «un minuto». Si la web llama a una pasarela de pago, a un servicio de envíos o a una API externa, durante la prueba se sustituyen por stubs o por los entornos de pruebas de esos servicios.
- Avise al proveedor. La protección DDoS del proveedor puede tomar la prueba por un ataque y bloquear la dirección del generador, y las normas de algunos proveedores exigen acordar este tipo de comprobaciones. Por ejemplo, la política de AWS permite pruebas de estrés de sus propios servicios preparados, pero prohíbe simular ataques DDoS. Un correo breve al soporte con la fecha, la hora, las direcciones y el volumen previsto resuelve la cuestión. Cómo funciona la protección de los proveedores se explica en el artículo Protección DDoS: qué ofrecen de verdad los proveedores.
- No en hosting compartido. En un servidor compartido, la prueba ralentizará a los vecinos y el resultado dependerá de ellos. Se prueba en un VPS o en un servidor dedicado, con recursos asignados a usted.
- El generador, en otra máquina. Si se lanza en el mismo servidor, le quitará procesador a la web. Para el generador resulta práctico un VPS con pago por horas: se crea para la prueba y se elimina después. Según el catálogo de accsly.io (noviembre de 2026), el pago por horas figura de forma expresa en 173 de 2247 proveedores de VPS; los planes están reunidos en la página VPS con pago por horas.
- Tenga en cuenta el tráfico. Una hora de prueba puede mover cientos de gigabytes. Si el plan tiene tráfico limitado o el canal se comparte con los vecinos, el exceso se paga o se reduce la velocidad; más detalles en el artículo Ancho de banda y tráfico: qué significan 1 Gbit/s e «ilimitado».
- CDN y protección delante de la web. Si el dominio está conectado a una CDN, la prueba a través de ella medirá la CDN y puede toparse con sus límites. El servidor de origen se prueba directamente por su dirección, y la carga a través de la CDN se acuerda con el proveedor de la CDN.
Cómo leer el resultado y elegir plan
Cuando la carga sube por escalones, al principio el RPS crece con ella y el tiempo de respuesta apenas cambia. Luego se llega al punto de saturación: el RPS deja de crecer, el p95 se dispara y aparecen errores. La carga de trabajo debe quedar claramente por debajo de ese punto, porque hace falta margen para picos, tareas en segundo plano y el crecimiento de la audiencia. Una referencia práctica: que el pico esperado no supere la mitad del límite encontrado.
Después se mira qué ha frenado el servidor en el punto de saturación:
- procesador al 100 %: hacen falta más núcleos, o una frecuencia más alta si el cuello de botella está en un solo hilo; los planes con frecuencia desde 4 GHz están reunidos en la página VPS con procesador de alta frecuencia;
- memoria agotada y el servidor tirando de swap: hace falta más memoria o menos procesos de PHP-FPM y workers; las referencias de tamaño están en el artículo Cuánta memoria y cuántos núcleos necesita una web;
- iowait alto: el disco no da abasto, normalmente por la base de datos; ayudan NVMe y los índices, y la comparación está en el artículo NVMe o SSD: ¿hay diferencia para una web?;
- recursos libres pero con errores: el límite está en la configuración, como el número máximo de conexiones de la base de datos, el número de workers del servidor web o de archivos abiertos.
Antes de comprar, conviene repetir la prueba en el plan que piensa contratar: los procesadores y discos de los proveedores varían más de lo que indican las cifras de la descripción. Lo más cómodo es hacerlo con pago por horas o durante el periodo de prueba, como se explica en el artículo Cómo probar el ping y la velocidad de un VPS antes de pagar. Tras el lanzamiento, esos mismos indicadores (tiempo de respuesta, errores y uso de recursos) se trasladan a la monitorización, para que el aumento de carga se vea antes de que la web empiece a responder con errores.