Calculadora de Recursos VPS

No es el nombre del paquete, sino el comportamiento de la carga

Al elegir un VPS, el nombre del paquete engaña fácilmente. “Basic”, “standard”, “premium”, “general purpose”… Se ven bien. Pero ninguno de esos nombres por sí solo dice cuánta RAM consumirá el sitio, cuándo asfixiará la CPU o en qué día se llenará el disco.

Un sitio estático y una tienda WooCommerce, aunque reciban al mismo visitante, no necesitan el mismo servidor. En uno se sirven archivos listos; en el otro hay carrito, pago, stock, sesión de usuario, consultas a la base de datos, panel de administración y, a veces, trabajos en cola ejecutándose en segundo plano. La diferencia está justamente ahí.

Este modelo de cálculo lee el VPS a través de cuatro recursos principales: vCPU, RAM, disco y tráfico mensual. Pero no los toma como números desnudos; los evalúa junto con el tipo de aplicación, el nivel del entorno, el uso de caché/CDN, los servicios que se ejecutan dentro del mismo VPS, los registros, las copias de seguridad locales y el margen de crecimiento.

No existe una única “fórmula oficial de VPS”. De hecho, en la documentación de los grandes proveedores de nube el tema se aborda así: CPU, memoria, red y almacenamiento se consideran juntos; las familias de máquinas se separan según la carga de trabajo. Las máquinas de propósito general se comportan de una manera, las de cómputo intensivo de otra, y las de memoria intensiva de otra. En el lado de los VPS aplica la misma lógica, solo que a una escala más pequeña.

flowchart LR
  A["Tipo de aplicación"] --> E["Estimación de recursos"]
  B["Tráfico y caché"] --> E
  C["Base de datos, worker, panel de administración, Docker"] --> E
  D["Disco, registros, copias de seguridad, margen de crecimiento"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["Disco"]
  E --> I["Tráfico mensual"]

La frase que más detesto en este tipo de cálculos es: “2 vCPU son suficientes.” ¿Suficientes para qué? ¿Para un sitio estático, WooCommerce, Odoo, una API de Node, o una instalación mixta que ejecuta MySQL, Redis, correo y Docker en la misma caja?

Además, se pasa por alto la diferencia entre CPU compartida y CPU dedicada. En los planes VPS pequeños, la CPU suele ser compartida. Para sitios web ligeros puede no ser un problema. Pero en sistemas que ejecutan workers con regularidad, reciben tráfico repentino, generan informes o cargan con frecuencia la base de datos, el mismo número de vCPU puede sentirse más débil de lo esperado.

Por eso, el resultado aquí no debe leerse como un “plan definitivo”, sino como una estimación inicial segura. Ofrece una buena primera fotografía para la selección de recursos. En producción, la última palabra la tienen las métricas: uso de CPU, consumo de RAM, llenado de disco, tráfico de red, consultas lentas, registros de errores y cola de workers.

El papel es una cosa, el servidor es otra.

¿Por dónde empezamos?

La primera distinción del cálculo proviene del tipo de aplicación. Porque la carga base de cada clase de aplicación no es la misma.

El sitio estático se encuentra en el lado más ligero. Se asume una CPU base de 1 vCPU, una RAM base de 1 GB; el factor de CPU también se mantiene bajo, como 0.2. Esto tiene sentido. Porque en un sitio estático bien cacheado, el servidor suele servir archivos listos y la capa de aplicación trabaja muy poco.

Para WordPress / blog, el punto de partida sube: CPU base 1.5 vCPU, RAM base 2 GB, factor de CPU 1. WordPress tiene una base de PHP y base de datos. Entre temas, plugins, procesamiento de imágenes, operaciones de administración, búsquedas y comentarios, no se comporta como un sitio estático. Aun así, con un buen caché se puede aliviar bastante.

WooCommerce / comercio electrónico es otra clase. En este modelo se toman una CPU base de 2.5 vCPU, una RAM base de 4 GB y un factor de CPU de 2. Si me preguntan, esta distinción es imprescindible para el comercio electrónico. Porque WooCommerce añade sobre WordPress plano una capa de carrito, pago, pedidos, stock y membresías. Además, algunas páginas no son aptas para el caché completo. La página de producto puede venir del caché, pero en el lado del carrito y del pago la cosa cambia.

Para una aplicación Laravel / PHP y Node.js / API: CPU base 2 vCPU, RAM base 3 GB, factor de CPU 1.2. Aquí la necesidad real depende mucho del código. Una API simple puede funcionar muy ligera; una aplicación que habla con servicios externos, procesa datos constantemente y usa colas puede ser mucho más pesada dentro de la misma clase.

Para un SaaS pequeño: CPU base 3 vCPU, RAM base 4 GB, factor de CPU 1.8. La sesión de usuario, los trabajos en segundo plano, las notificaciones, los informes y el tráfico de la base de datos suelen venir juntos. El número de visitantes puede parecer bajo, pero hay mucha operación dentro de la aplicación. Si se lo mira como si fuera un sitio web, se elige el paquete equivocado.

Los sistemas tipo Odoo / ERP están en el lado pesado: CPU base 4 vCPU, RAM base 8 GB, factor de CPU 3. En las instalaciones de Odoo, la planificación de workers y memoria ya se considera por separado. Los informes, la sesión de usuario, los módulos, las operaciones de base de datos y las tareas de larga duración distinguen esta clase de un sitio de blog normal.

Para un servidor de juegos: CPU base 3 vCPU, RAM base 4 GB, factor de CPU 2.5; en el lado de bot / worker se asumen CPU base 2 vCPU, RAM base 2 GB y factor de CPU 1.5. Especialmente en trabajos tipo worker, el número de visitantes puede ser engañoso. Aunque nadie entre al sitio, hay datos procesándose en segundo plano.

La elección del entorno se aplica como un coeficiente sobre el valor base. Se considera un coeficiente de 0.75 para un entorno de prueba / hobby, 1 para producción pequeña, 1.25 para producción y 1.6 para preparación de alta disponibilidad. Preparación de alta disponibilidad no significa que “un solo VPS ahora es HA”; simplemente significa dejar un margen de recursos más amplio. Un HA real requiere una arquitectura separada.

El margen de crecimiento entra en juego al final. El valor predeterminado es 30%. Me parece razonable. Es un buen rango para cubrir la expectativa de crecimiento de 3 a 6 meses. Se puede escribir 300%, pero si no se espera realmente ese crecimiento, el cálculo se convierte en un cálculo de miedo.

Cálculo de tráfico: el promedio mensual engaña un poco

El número de visitantes mensuales es el primer dato a mirar, pero resulta débil para la decisión final. Dos sitios con 100 mil visitantes pueden no generar la misma carga. Uno muestra 1.5 páginas por visitante, con un tamaño de página de 1 MB, y el CDN funciona bien. El otro muestra 4 páginas por visitante, con un tamaño de página de 3 MB, y tiene más áreas dinámicas. El mismo visitante, una carga de servidor completamente diferente.

El cálculo de tráfico considera juntos el número de visitantes, el valor de páginas / sesión y el tamaño promedio de página. Luego se descuenta el efecto del caché, se añade el margen de crecimiento y el resultado se convierte a GB. El valor final se redondea a escalones de 50 GB; incluso en escenarios muy pequeños se muestra un tráfico mínimo de 50 GB.

Los supuestos utilizados en el lado del caché son los siguientes: sin caché, ahorro 0; caché básica, 35%; caché de página + objeto, 60%; CDN + caché fuerte, 75%. No son valores de garantía oficiales. Cuando se usa caché NGINX o CDN, se espera que la carga del servidor de origen disminuya; pero el ahorro real depende de la tasa de aciertos del caché, la estructura de la página y las áreas dinámicas.

Presta especial atención a esto en WooCommerce. El hecho de que haya CDN no significa que el carrito y la página de pago de repente sean gratis. En lugares como contenido personalizado, sesión, operaciones de administración, flujo de pago y control de stock, el caché es más limitado. El caché es un buen freno; no reemplaza al motor.

Además está el factor de horas pico. El tráfico mensual no se distribuye uniformemente. Día de campaña, envío de boletines, compartir en redes sociales, picos repentinos en sitios de noticias… Mientras el valor promedio parece tranquilo, el servidor puede sudar durante una hora. En este cálculo, el RPS pico se obtiene aproximadamente dividiendo (visitantes mensuales × páginas / sesión × factor de horas pico) por el número de segundos en 30 días. 30 días son 2.592.000 segundos.

El efecto del tráfico en la CPU es aún más interesante. El número de visitantes se escala a 50.000, se multiplica por el factor de CPU, se añade el factor de horas pico y se descuenta la mitad del efecto del caché en el lado de la CPU. Es decir, el caché reduce seriamente el tráfico, pero el efecto en la CPU se reduce con más cautela. Creo que es el enfoque correcto; porque no todas las solicitudes provienen del caché.

En la prueba de un sitio estático con caché, con 100 mil visitantes mensuales, 1.5 páginas / sesión, tamaño de página de 1 MB, factor de horas pico de 2, CDN + caché fuerte y margen de crecimiento del 20%, el resultado se mantiene en 1 vCPU, 2 GB de RAM, 40 GB de disco y 50 GB de tráfico mensual. Hay tráfico, pero la carga es ligera.

En el ejemplo de comercio electrónico no hay la misma comodidad. Con 200 mil visitantes mensuales, 4 páginas / sesión, tamaño promedio de página de 3 MB, factor de horas pico de 5, caché de página + objeto y margen de crecimiento del 50%, el tráfico mensual sube a 1450 GB. La recomendación de CPU es 32 vCPU. A primera vista puede parecer alto; pero al juntar los números, el panorama se endurece: más visitantes, más páginas, páginas más grandes, carga de trabajo más pesada, picos más altos.

El tamaño de la página es otro dolor de cabeza. Decir “el sitio es ligero” no basta; hay que medirlo. Imágenes grandes, fuentes, scripts de terceros, códigos de publicidad, etiquetas de analítica y archivos JS innecesarios inflan el tráfico. El hecho de que se abra rápido en el navegador no significa que la transferencia de datos sea pequeña.

¿Quiénes trabajan en la misma caja?

En los VPS pequeños, la verdadera pelea suele aparecer aquí. El servidor web no está solo. MySQL está en el mismo lugar, Redis también, el panel también, y quizás el servicio de correo. Cuando además se añaden contenedores Docker y procesos worker, a 2 GB de RAM se les corta la respiración.

Si la base de datos está dentro del mismo VPS, el modelo añade una carga extra de RAM. El tamaño de la base de datos se divide entre 20; el resultado se limita a un mínimo de 1 GB y un máximo de 8 GB. Por ejemplo, incluso para una base de datos de 5 GB se reserva 1 GB de RAM. Para una base de datos de 30 GB, se genera una carga extra de alrededor de 1.5 GB. En el lado de la CPU, se añaden 0.5 vCPU para la base de datos.

Estos valores no son un cálculo de ajuste de base de datos. Si los índices son malos, las consultas son largas o hay bloqueos de tabla, 0.5 vCPU no es suficiente. Pero para la planificación inicial, es mejor que considerar la base de datos como de “costo cero”.

Si Redis / object cache está dentro del mismo VPS, se añaden 0.5 GB a la RAM. Redis trabaja en memoria; si lo olvidas, aparecen extrañas ralentizaciones en un servidor pequeño. Está instalado para mejorar el rendimiento del caché, sí, pero él mismo también necesita RAM.

En el panel de administración hay tres niveles: ninguno, panel ligero y panel completo tipo cPanel / Plesk. El panel ligero añade 0.3 GB a la RAM y 0.15 vCPU a la CPU. El panel completo añade 1 GB a la RAM y 0.3 vCPU a la CPU. Instalar sistemas tipo cPanel o Plesk en un VPS de 1 GB de RAM y luego esperar rendimiento de la aplicación no es buena idea. El panel da comodidad; se paga con recursos.

La cantidad de workers / colas afecta directamente. Se añaden 0.5 GB de RAM y 0.5 vCPU por cada worker. Puede parecer un poco alto, pero tiene sentido si los trabajos en segundo plano son serios. Procesamiento de imágenes, generación de informes, extracción de datos de una API externa, vaciado de la cola de correo, tareas posteriores al pago… Si el worker no está inactivo, consume recursos.

Si el servicio de correo se ejecuta dentro del mismo VPS, se añaden 0.5 GB de RAM y 0.3 vCPU. Aparte de la parte de recursos, el servicio de correo también es problemático operativamente. DNS, SPF, DKIM, DMARC, spam, cola, entregabilidad. Este cálculo solo ve la parte de recursos; no calcula el dolor de cabeza.

Para el uso de Docker / contenedores, se añaden 0.5 GB de RAM y 0.2 vCPU. Docker aporta orden, pero no es gratis. Si el límite de memoria, el comportamiento de swap y la proporción de CPU de Docker no se configuran correctamente, un contenedor puede comprimir toda la máquina. “Hicimos contenedores, estamos tranquilos” no siempre es una frase correcta.

La esencia del cálculo de CPU es así: se toma el mayor entre la CPU base y la necesidad de CPU por tráfico, se añaden las cargas de CPU de los servicios, se aplican el coeficiente de entorno y el margen de crecimiento. En RAM, se suman la RAM base y la RAM de servicios, y de nuevo se añaden entorno y margen de crecimiento. Luego el resultado se redondea a los escalones prácticos de paquete: en CPU, 1, 2, 4, 6, 8, 12, 16, 24, 32, 64; en RAM, 1, 2, 4, 8, 16, 32, 64, 128 GB.

No hay mundo de decimales. Si sale una necesidad de 5.3 GB de RAM, se mira a 8 GB. Si salen 3.1 vCPU, 4 vCPU es lo lógico. Hacer cálculos milimétricos en un entorno de producción acerca a la pared ante cualquier pequeña fluctuación.

En el disco, la carga real a veces son cosas invisibles

Se cree que la necesidad de disco es pequeña porque la carpeta del código es pequeña. Es un error de cálculo que vemos mucho. La aplicación ocupa 3 GB, los medios 10 GB; se dice “20 GB de disco son suficientes”. Luego llegan los registros, la base de datos, la copia de seguridad local, los archivos del sistema, las imágenes de contenedor y los archivos temporales.

El cálculo de disco se hace con los archivos de la aplicación, medios / uploads, tamaño de la base de datos, log diario, días de retención de logs y copia de seguridad local. Si la base de datos no está dentro del mismo VPS, no entra en el cálculo de disco. Si está dentro del mismo VPS, entra.

Primero se forma el subtotal de disco: archivos de aplicación + archivos de medios + base de datos si está en el mismo VPS + log diario × días de retención. Luego se tiene en cuenta el número de copias de seguridad locales. Una copia de seguridad local aproximadamente duplica el conjunto de datos. Se añade un margen de sistema de 15 GB, se aplica un margen de seguridad del 20%, y también se añade el margen de crecimiento. El resultado se redondea a escalones de 10 GB y se recomienda un mínimo de 20 GB.

Que el margen de sistema de 15 GB no parezca pequeño. El sistema operativo, los paquetes, los restos de actualizaciones, los archivos temporales, los registros de servicios, las imágenes de Docker y los archivos temporales de la base de datos comen de ahí. En producción, el disco no es solo tu carpeta de uploads.

Los registros también son traicioneros. 0.5 GB de log al día y 14 días de retención suman 7 GB. 2 GB de log al día y 30 días de retención suman 60 GB. Crecen en silencio. El disco pasa del 80%, luego al 90%, y luego durante un deploy llega ese famoso error: no space left on device.

La copia de seguridad local también requiere atención. Mantener la copia en el mismo disco no es una garantía total en un escenario de desastre; si el disco se pierde, la copia también. Pero una copia local puede servir para una recuperación rápida. El modelo incluye esto en el cálculo de recursos. Decisiones como copia remota, almacenamiento de objetos o un servidor de respaldo separado deben planificarse por separado.

En la prueba de producción de WordPress, con 5 GB de archivos de aplicación, 10 GB de medios, 5 GB de base de datos, 0.5 GB de log diario, 14 días de retención, 1 copia de seguridad local y 30% de margen de crecimiento, se recomiendan 90 GB de disco. A primera vista parece mucho. Pero al añadir logs, copia, margen de sistema y margen de seguridad, no es mucho, sino más bien prudente.

En el lado del comercio electrónico, el asunto crece: 10 GB de archivos de aplicación, 80 GB de medios, 30 GB de base de datos, 2 GB de log diario, 30 días de retención, 1 copia de seguridad local y 50% de margen de crecimiento. El disco resultante es de 480 GB. Si las imágenes de los productos, los datos de pedidos, los logs y la copia están en la misma caja, este resultado no sorprende.

Escatimar demasiado en el disco es un mal hábito. Si falta CPU, ves lentitud. Si falta RAM, empieza el swap. Si el disco se llena, los servicios a veces fallan de forma mucho más dura: la base de datos no puede escribir, no se crean logs, no se puede abrir el archivo de sesión, el deploy queda a medias. Peor aún, el error no siempre se explica claramente.

Al convertir el resultado en paquete

La salida tiene cuatro valores principales: CPU, RAM, disco y tráfico mensual. No los pongas en la misma bolsa. Cada uno indica un límite diferente.

La CPU es la potencia de procesamiento instantánea. Una petición PHP, una respuesta de API Node.js, una consulta a la base de datos, una tarea de worker, una operación posterior al pago… Todo eso toca la CPU. Cuando el tráfico aumenta, la CPU puede aumentar; el caché puede reducirlo, pero no lo elimina por completo.

La RAM es el espacio de los servicios en ejecución. MySQL, Redis, PHP-FPM, procesos Node.js, panel, contenedores Docker, servicio de correo, workers. Cuando la RAM disminuye, el sistema puede caer en swap. Sigue funcionando, pero se vuelve pesado. En aplicaciones dinámicas, esta diferencia se nota rápidamente.

El disco es el almacenamiento persistente. Archivos de aplicación, medios, base de datos, logs, copias de seguridad y archivos del sistema dependen de él. En el cálculo del disco hay que pensar no en el tamaño actual, sino en la acumulación de varios meses después.

El tráfico mensual es la transferencia de datos. CDN, caché y optimización de página lo reducen. La política de tráfico del proveedor debe consultarse por separado: ¿hay cuota, hay cargo por exceso, hay limitación de velocidad? El cálculo da la necesidad en GB; no da la condición comercial del proveedor.

En este modelo, los valores brutos se redondean a los escalones prácticos de paquete. Si hay una necesidad bruta de 3.4 vCPU, se recomienda 4 vCPU. Si hay una necesidad de 9 GB de RAM, puede subir al nivel de 16 GB. El disco también se completa a escalones de 10 GB. Este redondeo a veces hace que el resultado parezca más grande de lo que es, pero los paquetes VPS tampoco se venden con decimales.

Y además está esto: 4 vCPU puede no comportarse igual en todos los proveedores. La generación de la CPU, la estructura compartida / dedicada, la capa de virtualización, el tipo de disco, la calidad de la red y las máquinas vecinas, todo influye. No en vano, en los documentos de selección de planes de proveedores como DigitalOcean se enfatiza la distinción entre CPU compartida y dedicada.

Por eso, este cálculo debe pensarse como una verificación técnica antes de pulsar el botón de compra. Si tienes un sistema existente, ponlo junto a las métricas reales: gráfico de CPU, uso de RAM, llenado de disco, salida de red, consultas lentas, errores 5xx, tiempo de espera en la cola. Si estás montando un sistema nuevo, prueba varios escenarios.

¿Qué pasa sin caché? ¿Cuánto baja el tráfico al elegir CDN? ¿Al separar la base de datos del mismo VPS, la RAM se alivia? ¿A dónde va la CPU cuando el número de workers pasa de 0 a 4? ¿Cuánto agranda el disco una copia de seguridad local?

La elección del paquete a veces sale de las respuestas a estas preguntas, no de una única línea de resultado.

Si fuera yo, volvería a revisar especialmente tres valores: el factor de horas pico, si la base de datos está dentro del mismo VPS y la copia de seguridad local. Porque en la vida real son los que más desajustan el cálculo. El tráfico se concentra en una hora, MySQL consume más RAM de la esperada en la misma caja y las copias llenan el disco. Luego todos se enojan con el paquete de CPU.

A veces la culpa no es de la CPU.