Dimensionar un VPS SaaS a partir de un presupuesto de carga de trabajo

Nombre el trabajo antes de elegir el host

Trace la ruta de la solicitud: proxy inverso, proceso de API, base de datos y servicios externos. Añada la ruta asíncrona: cola, worker y destino de exportación. Registre qué componentes comparten el host, quién controla la concurrencia y qué datos deben sobrevivir a una reconstrucción. Necesita métricas de la aplicación y una carga de trabajo que no sea de producción con datos representativos; esta guía no asume una instancia de PrivacyNodes aprovisionada.

Para una API de informes ilustrativa, una solicitud HTTP lee la configuración de la cuenta y encola una exportación. El worker escanea filas y escribe un archivo. Una respuesta de encolado rápida no prueba que la exportación pueda terminar durante el tráfico máximo. Incluya la limpieza programada y la superposición de despliegue en el plan de prueba.

Incluya la superposición en la hoja de cálculo de memoria

Estas son entradas de planificación hipotéticas en MiB, no mediciones ni promesas sobre PrivacyNodes. Sustitúyalas por requisitos observados de la aplicación. RSS incluye asignaciones compartidas residentes; sumar el RSS de cada proceso puede duplicar la memoria. La memoria disponible del host es más útil que tratar toda la caché del sistema de archivos como permanentemente no disponible.

Referencia técnica: Linux contabilidad de memoria de procesos.

Esto está demasiado cerca de un envoltorio nominal de 4 GB como para asumir una capacidad cómoda. Compruebe la memoria real que reporta el host y si los picos se superponen. Reduzca la concurrencia, mueva un componente o añada memoria; no quite la reserva solo para que la tabla encaje.

PostgreSQL work_mem es una asignación por operación, no un límite total de la base de datos. Las sesiones y operaciones concurrentes pueden multiplicar su efecto. Los contenedores Docker no tienen restricciones de CPU ni memoria de forma predeterminada; una imagen no es una política de recursos.

Referencia técnica: Consumo de recursos de PostgreSQL · Restricciones de recursos de Docker.

Mida la CPU junto con la antigüedad de la cola

Ejercite una solicitud ordinaria, el informe útil más lento, una dependencia fallida y una exportación a la vez. Registre percentiles de latencia, errores, CPU del host, concurrencia de workers y antigüedad del trabajo más antiguo durante el mismo intervalo. La presión de CPU con crecimiento de la cola sugiere una acción distinta a una CPU baja con una espera larga en la base de datos.

Comience el ejemplo con una exportación en curso. Si el worker espera al almacenamiento externo, la CPU adicional puede cambiar poco. Si satura repetidamente un núcleo mientras aumenta la latencia de la API, pruebe un lote de exportación más pequeño o un presupuesto de worker separado. Cambie un factor y repita el mismo escenario antes de comprar capacidad.

Presupueste la próxima operación de mantenimiento

Enumere los archivos e índices de base de datos, las cargas, los registros, las exportaciones temporales, los artefactos de versión y el espacio libre para mantenimiento. Registre el crecimiento por semana y cuándo se agotaría su reserva. Un conjunto de datos de 20 GB más una copia temporal de 20 GB necesita más de 20 GB, incluso cuando el tráfico normal de la aplicación está tranquilo.

Asigne la rotación de registros y la caducidad de las exportaciones. Mantenga las copias de recuperación fuera del límite de fallo del host. El almacenamiento adicional del VPS amplía la asignación de trabajo; una copia en ese mismo disco no es una copia de seguridad independiente. Pruebe tanto el funcionamiento normal como una versión que se ejecute junto con una copia de seguridad o una exportación.

Escriba una decisión que se pueda revisar

Su resultado es una hoja de cálculo, una descripción de la carga de trabajo y un desencadenante de revisión: antigüedad creciente del trabajo más antiguo durante la prueba representativa, espacio de mantenimiento que se reduce o una versión que no puede coexistir con los procesos actuales. Registre observaciones en lugar de inventar un umbral universal de porcentaje de CPU.

Compare App 2 y Scale 4 con esas restricciones. Si el resultado aún le sorprende, siga una solicitud lenta por todo el stack. Este ejercicio estima su carga de trabajo; no establece ningún benchmark de proveedor, capacidad de tráfico ni disponibilidad.