Prueba de carga de Apache en un VPS pequeño
Fecha de publicación：
Actualizado:
Artículos técnicos > Prueba de carga de Apache en un VPS pequeño
Estado 2026 y uso seguro
Conclusión: Este artículo registra un experimento de VPS, no un límite de simultaneidad universal de Apache. La capacidad depende del trabajo de respuesta, MPM, límites de trabajadores, mantenimiento de actividad, TLS, CPU, memoria, almacenamiento, red, ubicación del cliente y el objetivo de latencia que defina como aceptable.
Qué aprenderás
- Cómo se organizó la prueba original y qué muestran (y qué no muestran) los números observados.
- Qué métricas de Apache y del sistema operativo ayudan a identificar el primer cuello de botella.
- Cómo diseñar una prueba de carga repetible con calentamiento, percentiles, errores y telemetría del lado del servidor.
Para quién: ingenieros que planean un experimento de primer paso con un servidor web en un VPS pequeño.
Situación en 2026: Las mediciones siguientes se conservan del entorno original del autor y no se volvieron a ejecutar para esta actualización. No los utilice como punto de referencia actual del proveedor o recomendación de tamaño de producción; Pruebe su propia aplicación y umbrales de error.
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ó un servidor Apache 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 llevado a cabo únicamente en el servidor WEB (Apache), pero en el artículo siguiente se pueden consultar las mediciones en los servidores WEB/AP (Apache y Tomcat).
Prueba de carga de Apache y Tomcat en un VPS
Í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 |
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 120 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 60 solicitudes simultáneas. |
|---|---|
| CPU：2core memory：1GB SSD：50GB | Se pueden procesar hasta 120 solicitudes simultáneas. |
| CPU：3core memory：2GB SSD：100GB | Se pueden procesar hasta 240 solicitudes simultáneas. |
En este benchmark concreto de páginas estáticas, el entorno con 1 núcleo de CPU, 512 MB de memoria y 25 GB de SSD completó la carga probada. El resultado no equivale a una cantidad de usuarios admitidos.
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 (Apache)
Se lanzaron peticiones repetidas contra páginas creadas en HTML. Se trata de una página sencilla, sin procesamiento PHP ni complejidad JavaScript.
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⇒OK
- Para 100 solicitudes simultáneas⇒OK
- 110 solicitudes simultáneas⇒OK
- Para 120 solicitudes simultáneas⇒OK
- Para 130 solicitudes simultáneas⇒NG
El error se produjo en el caso 130. 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%
- tasa de uso 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.
Parecía estar usando 960 MB de memoria (8M x 120 procesos) y el valor de ajuste era '250', pero parecía que no era posible crear más de '120' procesos.
Nota: La memoria del servidor está casi al límite de 1G.
Al operar realmente el servidor, si se incluyen también PHP y Java, el límite es de unos 100 casos, y si hay espacio, se pueden procesar 80 casos simultáneamente en paralelo.
Cuando sólo se instala y ejecuta Apache, con las especificaciones "CPU: 2core, memoria: 1GB, SSD: 50GB", el número de accesos simultáneos "120" resultó ser el límite.
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 cambia la memoria, el número de procesos que se pueden procesar simultáneamente aumentará.
【Presente.（memory1GB）】
- memory：1GB
- Número de hilos de Apache：120 casos
- Consumo de memoria por hilo en Apache.：8MB
- Consumo de memoria de Apache：960MB（120 casos×8MB）
【después del cambio（memory2GB）】
- memory：2GB
- Número de hilos de Apache：240 casos.
- Consumo de memoria por hilo en Apache.：8MB
- Consumo de memoria de Apache：1920MB（240 casos.×8MB）
Si se aumenta la memoria a 2 GB, es posible duplicar el número de casos a unos 240 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. 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：60 casos.
- Consumo de memoria por hilo en Apache.：8MB
- Consumo de memoria de Apache：480MB（60 casos.×8MB）
3. resumen
El artículo documenta una prueba de solicitudes simultáneas a Apache bajo condiciones concretas. La planificación de capacidad también debe considerar las respuestas reales, TLS, los picos de tráfico, el comportamiento de los clientes 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.