El tamaño de un VPS no se decide a partir de una cifra de visitas aislada. Una aplicación con páginas estáticas, una tienda con sesiones y una API que ejecuta consultas pesadas pueden recibir el mismo tráfico mensual y necesitar recursos muy diferentes. La unidad útil de planificación es el trabajo que debe completar el servidor en los momentos de mayor demanda.
Empieza por describir la aplicación, sus dependencias y qué resultado se considera aceptable. Después mide qué recurso limita la respuesta.
Describir la carga real
Registra solicitudes por segundo, concurrencia, rutas dinámicas, tamaño de respuestas, porcentaje de caché y duración de tareas de fondo. Un promedio mensual oculta picos de lanzamiento, campañas o copias. También importa si la carga llega de forma gradual o en ráfagas.
Una aplicación PHP puede tener poco uso de CPU en una hora normal y consumir mucha memoria cuando se activan varios workers y conexiones de base de datos. No conviertas esa observación en una fórmula universal: úsala como hipótesis que debe medirse.
CPU y paralelismo
La CPU debe atender peticiones, ejecutar PHP, comprimir contenido, procesar tareas y mantener servicios auxiliares. Más vCPU ayuda cuando existe trabajo paralelo suficiente, pero no resuelve una consulta lenta o un bloqueo de I/O. Observa uso sostenido, picos, tiempo de espera y posible contención.
Si una tarea es principalmente secuencial, añadir núcleos puede aportar menos que optimizar el algoritmo. El tipo de CPU y la política de asignación del VPS también influyen.
RAM, workers y base de datos
La memoria debe cubrir sistema, servidor web, runtime, workers, base de datos, cachés y margen para picos. Cada proceso PHP puede consumir una cantidad distinta según plugins, extensiones y tamaño de la petición. La base de datos necesita memoria para buffers y conexiones, pero aumentar buffers sin observar el conjunto puede provocar presión.
Cuenta tareas de cron, colas, generadores de informes y procesos de despliegue. El momento crítico puede ser la coincidencia de tráfico web y una tarea de importación.
Almacenamiento e I/O
Separa capacidad de rendimiento. Los archivos, subidas, logs, copias y base de datos ocupan espacio; las lecturas y escrituras concurrentes determinan la espera. Un disco con suficiente capacidad puede seguir siendo lento para una aplicación que genera muchos archivos temporales o consultas.
Define retención de logs y copias para evitar que el crecimiento consuma el volumen. Mide latencia de disco y cola de I/O antes de atribuir todos los retrasos a CPU.
Red, caché y tareas externas
Calcula transferencia de entrada y salida, tamaño de recursos y dependencia de APIs externas. La latencia de un proveedor de pagos o de una API puede dominar la respuesta aunque el VPS esté libre. La caché reduce trabajo repetido, pero debe excluir sesiones, carrito y contenido personalizado cuando corresponda.
Margen y picos
Dimensiona con margen sobre el pico observado, no sobre la media. El margen debe cubrir crecimiento razonable y variación, pero no sustituye un plan de ampliación. Si el servicio entra en swap o se forman colas largas, la degradación puede afectar a todas las rutas.
Medir antes de elegir
Usa pruebas representativas con tráfico anónimo y autenticado, consultas reales y tareas de fondo. Mide percentiles de latencia, errores, CPU, memoria, I/O y red. Una prueba de cinco segundos no revela cómo se comporta el sistema después de una hora de concurrencia.
Qué medir antes de ampliar o reducir el VPS
Relaciona cada síntoma con la métrica que lo confirma. Si falta memoria, revisa workers y procesos; si hay espera de base de datos, optimiza consultas; si el enlace se llena, analiza transferencia. El VPS adecuado es el que satisface la carga y el objetivo operativo con margen medible, no el que tiene más recursos por defecto.
Separar capacidad y responsabilidad
Un VPS ofrece control sobre sistema, servicios y configuración, pero ese control implica actualizar paquetes, revisar accesos, mantener copias y responder ante errores. El tamaño elegido debe incluir la capacidad del equipo para operar el entorno, no solo el coste de los recursos anunciados.
Una aplicación con base de datos en el mismo VPS puede ser sencilla de administrar al principio, pero concentra CPU, memoria e I/O. Separar servicios cambia la latencia y la complejidad, por lo que conviene justificarlo con métricas y no con una regla general.
Escalar sin adivinar
Un aumento vertical puede resolver temporalmente un límite de memoria o CPU, mientras que el horizontal exige distribuir tráfico y gestionar estado. Antes de cambiar, conserva una línea base y define qué métrica dispara la siguiente acción. El plan debe incluir copia, ventana de cambio y una forma de volver a la configuración anterior.
Una prueba de capacidad realista
Reproduce consultas representativas sin usar datos personales innecesarios y observa el sistema durante un periodo sostenido. Incluye picos, tareas de fondo, invalidación de caché y errores de servicios externos. La prueba no necesita imitar todo el tráfico, pero sí los recursos que pueden coincidir en producción.
Capacidad para crecimiento y recuperación
Reserva margen para actualizaciones, copias y una incidencia, pero define cuándo dejará de ser suficiente. Un servicio puede crecer en almacenamiento antes que en CPU, o necesitar separar la base de datos antes de agotar memoria. El orden de esas decisiones depende de las métricas observadas.
Documenta la configuración inicial, los límites y las acciones de retorno. Así un cambio de plan se convierte en una decisión verificable y no en una sucesión de ampliaciones motivadas por síntomas distintos.