¿Cuántos usuarios simultáneos soporta un VPS? Hacer el cálculo

De los usuarios a las peticiones

«Usuarios simultáneos» designa tres magnitudes distintas según quién hable:

• Las cuentas registradas: no le cuestan nada al servidor mientras no se conectan.
• Los usuarios activos al mismo tiempo: personas que navegan, leen o rellenan un formulario. Cada una envía una petición de vez en cuando, típicamente cada 10 a 30 segundos, más algunas llamadas a la API por pantalla en una aplicación moderna.
• Las peticiones en curso de procesamiento: las que el servidor calcula en un instante dado. Es la única magnitud que consume procesador y memoria.

Se pasa de una a otra con la ley de Little: el número de peticiones en curso es igual al caudal, en peticiones por segundo, multiplicado por la duración media de una petición.

Ejemplo. 600 usuarios activos al mismo tiempo, que lanzan cada uno una petición cada 20 segundos, generan 30 peticiones por segundo. Si cada petición dura 100 ms, el servidor solo tiene 3 peticiones en curso de media. Lo que está en juego se encuentra en otra parte: en los picos y en las peticiones lentas.

Lo que sostiene un vCPU

Una petición ocupa el procesador durante su cálculo: ejecutar el código, consultar la base de datos, construir la respuesta. Un vCPU procesa, por tanto, como máximo 1000 ÷ t peticiones por segundo, donde t es el tiempo de cálculo de una petición en milisegundos. El tiempo de espera (una API externa, un disco) deja libre el procesador, pero sí ocupa un worker.

Con estos órdenes de magnitud, 30 peticiones de API por segundo a 10 ms de cálculo ocupan el 30 % de un solo vCPU. Las mismas 30 peticiones por segundo sobre páginas WordPress sin caché piden de 3 a 9 vCPU. La caché de páginas sirve precisamente para que una página pase de la cuarta fila de la tabla a la segunda.

Lo que sostiene la memoria

Cada petición en curso la atiende un worker, y los workers ocupan memoria, trabajen o no. A menudo es la memoria, más que el procesador, la que fija el número de peticiones procesadas en paralelo:

• PHP-FPM: un proceso por petición en curso, de 40 a 80 MB cada uno. pm.max_children fija el tope: 20 procesos son de 800 MB a 1,6 GB.
• Python (Gunicorn, Uvicorn): la documentación de Gunicorn propone partir de (2 × número de núcleos) + 1 workers, de 80 a 200 MB cada uno. Un worker asíncrono mantiene muchas peticiones en espera con la memoria de un solo proceso.
• Node.js: un solo proceso mantiene miles de conexiones en espera, pero solo usa un núcleo; el modo clúster, o PM2, lanza un proceso por vCPU.
• La base de datos: PostgreSQL abre un proceso por conexión y acepta 100 por defecto. Por encima de unas decenas de conexiones activas, un pooler como PgBouncer es mejor opción que subir max_connections.

Las conexiones persistentes (websockets, notificaciones en tiempo real) se cuentan aparte: abiertas de forma permanente, ocupan poco procesador y unas decenas de kilobytes de memoria cada una. Un servidor Node.js mantiene miles de ellas en unos cientos de MB.

Los verdaderos cuellos de botella

En una aplicación real, el servidor rara vez se satura donde se espera. Las causas más frecuentes, en el orden en que conviene buscarlas:

1. Una consulta SQL lenta: un índice ausente convierte una consulta de 2 ms en una de 2 segundos, que retiene un worker y una conexión. pg_stat_statements en PostgreSQL, o el registro de consultas lentas de MySQL, la señala.
2. Las consultas en cascada (el problema N+1): una página que lanza una consulta por cada fila mostrada lanza cientos.
3. Una llamada externa síncrona: una API de pago o de IA que responde en 3 segundos bloquea un worker síncrono durante 3 segundos.
4. Procesos pesados dentro de la petición: envío de correos, redimensionado de imágenes, generación de PDF, que conviene trasladar a una cola de tareas.
5. La ausencia de caché: las páginas idénticas para todos los visitantes se sirven desde una caché, y los archivos estáticos desde el servidor web.

Verificarlo: la prueba de carga

Los órdenes de magnitud dan un primer tamaño; una prueba de carga da el real. El principio: simular usuarios cada vez más numerosos sobre una copia de la aplicación, y anotar el momento en que el tiempo de respuesta se dispara.

wrk -t2 -c50 -d30s --latency https://preprod.su-sitio.com/

Para un recorrido completo (inicio de sesión, navegación, búsqueda), k6 describe un escenario en JavaScript y hace subir la carga por escalones:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 300 },
    { duration: '5m', target: 300 },
    { duration: '2m', target: 0 },
  ],
  thresholds: { http_req_duration: ['p(95)<500'] },
};

export default function () {
  http.get('https://preprod.su-sitio.com/');
  sleep(15);
}

• Pruebe una copia, no la producción, y avise a su proveedor de hosting si la prueba apunta a un servidor que él explota.
• Lance la prueba desde otra máquina distinta del servidor probado; si no, la herramienta le quita sus propios recursos.
• Mire el percentil 95 del tiempo de respuesta, no la media: es lo que viven sus usuarios peor atendidos.
• Observe el servidor durante la prueba: htop para el procesador, free -h para la memoria, los registros para los errores.

Cuando la carga crece

El orden que menos cuesta y más aporta:

1. Poner en caché lo que se pueda (páginas, fragmentos, resultados de consultas) y corregir las consultas lentas.
2. Ajustar el número de workers a la memoria y al procesador disponibles.
3. Pasar a un tamaño superior: más vCPU y más memoria, sin cambiar nada en la aplicación.
4. Colocar la base de datos en su propio servidor.
5. Repartir la aplicación entre varios servidores detrás de un balanceador de carga.

Las tres primeras etapas cubren la gran mayoría de las aplicaciones de gestión, los sitios web y las API: varios cientos de usuarios activos al mismo tiempo caben en un solo servidor bien ajustado.