Prueba de carga de Apache y Tomcat en un VPS
Fecha de publicación：
Actualizado:
Artículos técnicos > Prueba de carga de Apache y Tomcat en un VPS
Estado 2026 y uso seguro
Conclusión: En una pila de Apache a Tomcat, el primer límite puede ser el cliente, los trabajadores proxy, los subprocesos del conector, el montón de JVM o la recolección de basura, el código de la aplicación, la base de datos o el propio VPS. Un único número de simultaneidad no puede identificar la capacidad sin evidencia de latencia, error y recursos.
Qué aprenderás
- Lo que midió el experimento original de VPS de dos niveles.
- Cómo interactúan los límites del conector Tomcat y el proxy con el tiempo de respuesta de la aplicación.
- Qué registrar en una prueba moderna: percentiles, rendimiento, fallas, CPU, memoria, GC, subprocesos y saturación descendente.
Para quién: equipos web de Java que aprenden a diseñar una pequeña prueba de capacidad basada en evidencia.
Situación en 2026: Los resultados siguientes pertenecen a la prueba original del autor y no se reprodujeron para esta actualización editorial. Trátelos como un caso de estudio, no como un rendimiento actual verificado ni como una recomendación de compra de VPS.
Nota de seguridad: Los comandos y ejemplos de configuración del artículo original no se han vuelto a ejecutar en un entorno de producción actual. Verifique las versiones compatibles, las copias de seguridad, los controles de acceso y los pasos de reversión en un entorno de prueba independiente antes de aplicarlos.
Fuentes primarias oficiales
Resumen.
Esta prueba histórica mide cuántas solicitudes simultáneas procesó una pila Apache y Tomcat en el entorno del autor. Los resultados son un caso práctico, no una guía actual para dimensionar un VPS.
En esta ocasión, las mediciones se han realizado en los servidores WEB/AP (Apache y Tomcat), pero en el artículo siguiente se pueden consultar las mediciones sólo en el WEB (Apache).
Prueba de carga de Apache en un VPS pequeño
Índice de contenidos
1. medición
1-1. Entorno de medición
A continuación se muestra el entorno en el que se realizarán las mediciones.
■Información sobre el servidor de alquiler
| CPU | 2core |
|---|---|
| memory | 1GB |
| SSD | 50GB |
■Información del servidor
| OS | CentOS 7.4 64bit |
|---|---|
| Servidor web | Apache HTTP Server 2.4.41 |
| Servidor AP | Apache Tomcat 9.0.27 |
| Servidor de BD | PostgreSQL 10.2 |
| Java | OpenJDK 11 |
1-2. Método de medición
La prueba utiliza JMeter, una herramienta de carga para Java, y aumenta las solicitudes simultáneas hasta que el servidor deja de procesarlas al ritmo requerido.
Las condiciones específicas incluyen.
- intervalo de solicitud: 5 seg.
- Número de solicitudes simultáneas: 10 casos.（Las mediciones aumentaron gradualmente en 10 casos cada una.）
- Medición del tiempo: 60 segundos.
El tiempo de medición es de "60 segundos" y el intervalo de solicitud de "5 segundos", por lo que se quiere acceder al sistema 12 veces (60÷5) repetidamente.
1-3. resultado de la medición
Los resultados aparecen primero y solo son aplicables al entorno de prueba descrito.
| CPU：2core memory：1GB SSD：50GB | Se pueden procesar hasta 80 solicitudes simultáneas |
|---|
Los resultados de esta medición mostraron lo anterior. Los resultados anteriores permiten inferir lo siguiente. Intente utilizar este criterio a la hora de elegir las especificaciones del servidor.
| CPU：1core memory：512MB SSD：25GB | Se pueden procesar hasta 20 solicitudes simultáneas. |
|---|---|
| CPU：2core memory：1GB SSD：50GB | Se pueden procesar hasta 80 solicitudes simultáneas |
| CPU：3core memory：2GB SSD：100GB | Se pueden procesar hasta 200 solicitudes simultáneas. |
En este benchmark concreto de Apache y Tomcat, el entorno con 1 núcleo de CPU, 512 MB de memoria y 25 GB de SSD completó la carga probada. El resultado no demuestra una capacidad de 20 usuarios simultáneos o registrados en producción.
2. Detalles de los resultados de las mediciones
Las secciones siguientes documentan las condiciones y los resultados para dejar claro el alcance limitado de las cifras.
2-1. Medidas del servidor WEB/AP (Apache, Tomcat)
La solicitud fue lanzada en un escenario en el que el usuario se conecta desde la pantalla de inicio de sesión y después de iniciar la sesión, se muestra la pantalla de la lista. Por cierto, la pantalla está construida con el framework de Spring, incluyendo la función de autenticación.
Las mediciones mostraron los siguientes resultados.
- Para 10 solicitudes simultáneas⇒OK
- Para 20 solicitudes simultáneas⇒OK
- Para 30 solicitudes simultáneas⇒OK
- Para 40 solicitudes simultáneas⇒OK
- Para 50 solicitudes simultáneas⇒OK
- Para 60 solicitudes simultáneas⇒OK
- Para 70 solicitudes simultáneas⇒OK
- Para 80 solicitudes simultáneas⇒OK
- Para 90 solicitudes simultáneas⇒NG
El error se produjo en el caso 90. La causa era un error de conexión con Apache. El estado del servidor en ese momento era el siguiente.
- Utilización de la CPU: 26%
- utilización de la memoria: 100%
La falta total de memoria era el cuello de botella.
Para los más frikis, la configuración del módulo de multiprocesamiento de Apache (MPM) es la siguiente. MPM se explica simplemente como la configuración de la cantidad de Apache que se permite procesar en paralelo.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 250
MaxConnectionsPerChild 0
</IfModule>
El ajuste de interés es "250" para "MaxRequestWorkers". Este es un ajuste para el número máximo de casos que Apache puede procesar al mismo tiempo. '250', por lo que se podían procesar 250 casos en paralelo máximo, pero mirando el uso de la memoria, se utilizaban unos 8 MB de memoria por caso.
Java parecía estar usando 320MB de memoria (248M para el heap y 72M para el metaspace) y Apache 640MB de memoria (8M x 80 procesos), y aunque el valor de configuración del MPM de Apache es '250', parecía que no podía crear más de '80' procesos.
Nota: El servidor tiene 1G de memoria, por lo que la memoria total para Apache y Java es de 960MB, que está casi en el límite superior.
En esta prueba, el lado de Apache alcanzó primero su límite. La observación solo identifica el cuello de botella de esa configuración y esa carga.
Cuando Apache y Tomcat están instalados y funcionando, encontramos que con las especificaciones "CPU: 2core, memoria: 1GB, SSD: 50GB", el número de accesos simultáneos "80" es el límite.（Se supone que la configuración de memoria para Java es de 248M para el heap y 72M para el metaspace.）
2-2. consideración
A partir de aquí se convierte en una consideración, pero como la memoria es el cuello de botella, si se modifica la memoria, también aumentará el número de procesos que se pueden procesar simultáneamente.
【Presente.（memory1GB）】
- memory：1GB
- Número de hilos de Apache：80 casos.
- Consumo de memoria por hilo en Apache.：8MB
- Consumo de memoria de Apache：640MB（80 casos.×8MB）
- Consumo de memoria de Tomcat：320MB（248 millones de euros para el HEAP.、72m para el metaespacio.）
- Consumo de memoria de Apache+Tomcat：960MB
【después del cambio（memory2GB）】
- memory：2GB
- Número de hilos de Apache：200 casos
- Consumo de memoria por hilo en Apache.：8MB
- Consumo de memoria de Apache：1600MB（200 casos×8MB）
- Consumo de memoria de Tomcat：320MB（248 millones de euros para el HEAP.、72m para el metaespacio.）
- Consumo de memoria de Apache+Tomcat：1920MB
Con 2 GB de memoria, puede ser posible procesar 200 casos simultáneamente. Si se aumenta la memoria a 3GB, parece que se puede hacer más procesamiento concurrente, pero el "MaxRequestWorkers (número máximo de casos a procesar concurrentemente)" del MPM de Apache es "250", por lo que el ajuste aquí también será necesario si se aumenta más la memoria. También puede ser necesario ajustar la memoria de Java. Por el contrario, si la memoria se reduce a la mitad, sería como sigue.
【después del cambio（memory512GB）】
- memory：512GB
- Número de hilos de Apache：20 casos
- Consumo de memoria por hilo en Apache.：8MB
- Consumo de memoria de Apache：160MB（20 casos×8MB）
- Consumo de memoria de Tomcat：320MB（248 millones de euros para el HEAP.、72m para el metaespacio.）
- Consumo de memoria de Apache+Tomcat：480MB
3. resumen
El artículo documenta solicitudes simultáneas a Apache y Tomcat bajo condiciones concretas. La planificación de capacidad debe incluir la lógica de negocio real, la base de datos, TLS, los picos de tráfico y la latencia aceptable; esta medición no determina una cifra fija de usuarios.
La encuesta se basa en la suposición de que ningún otro software está funcionando con un rendimiento marginal. Se recomienda elegir una especificación con un poco de margen, ya que es un valor marginal.