Test de charge d’Apache et Tomcat sur un VPS
Date de publication:
Mise à jour :
Articles > Test de charge d’Apache et Tomcat sur un VPS
Statut 2026 et utilisation sûre
Conclusion : Dans une pile Apache vers Tomcat, la première limite peut être le client, les proxy Workers, les threads de connecteur, le tas JVM ou le garbage collection, le code d'application, la base de données ou le VPS lui-même. Un seul numéro de simultanéité ne peut pas identifier la capacité sans preuve de latence, d'erreur et de ressources.
Ce que vous apprendrez
- Ce que mesurait l'expérience VPS à deux niveaux d'origine.
- Comment les limites du proxy et du connecteur Tomcat interagissent avec le temps de réponse des applications.
- Ce qu'il faut enregistrer dans un test moderne : percentiles, débit, pannes, processeur, mémoire, GC, threads et saturation en aval.
À qui s'adresse : les équipes Web Java apprennent à concevoir un petit test de capacité basé sur des preuves.
Note de mise à jour (2026) : Les résultats ci-dessous appartiennent au test original de l'auteur et n'ont pas été reproduits pour cette mise à jour éditoriale. Traitez-les comme une étude de cas, et non comme des performances actuelles vérifiées ou une recommandation d'achat de VPS.
Note de sécurité : les commandes et exemples de configuration de l'article d'origine n'ont pas été rejoués dans un environnement de production actuel. Avant toute application, vérifiez les versions prises en charge, les sauvegardes, les contrôles d'accès et la procédure de retour arrière dans un environnement de test isolé.
Sources primaires officielles
Vue d’ensemble
J'ai mesuré le nombre maximum de cas que les serveurs WEB/AP (Apache et Tomcat) peuvent traiter en même temps, et je voudrais écrire sur les résultats. Nous étions curieux de connaître le nombre maximum de demandes pouvant être servies, nous avons donc mené une enquête. Utilisez-le comme référence pour sélectionner les spécifications du serveur VPS.
Cette fois, les mesures ont été effectuées sur les serveurs WEB/AP (Apache et Tomcat), mais veuillez vous référer à l'article ci-dessous pour les mesures sur le WEB (Apache) uniquement.
Test de charge d’Apache sur un petit VPS
Table des matières
1. mesure
1-1. Environnement de mesure
Voici l'environnement dans lequel les mesures seront effectuées.
■Informations sur le serveur de location
| CPU | 2core |
|---|---|
| memory | 1GB |
| SSD | 50GB |
■Informations sur le serveur
| OS | CentOS 7.4 64bit |
|---|---|
| Serveur web | Apache HTTP Server 2.4.41 |
| Serveur AP | Apache Tomcat 9.0.27 |
| Serveur de base de données | PostgreSQL 10.2 |
| Java | OpenJDK 11 |
1-2. Méthode de mesure
Je voudrais mesurer cela en utilisant JMeter. JMeter est un outil de mesure de charge qui fonctionne en Java. Cet outil permet de lancer un grand nombre de requêtes en même temps. Nous souhaitons augmenter progressivement le nombre de demandes simultanées à l'aide de JMeter et augmenter la charge jusqu'à ce que le traitement ne puisse plus être géré.
Les conditions spécifiques comprennent.
- intervalle de demande: 5 sec.
- Nombre de demandes simultanées: 10 cas. (Les mesures ont augmenté progressivement de 10 cas chacune.)
- Temps de mesure: 60 secondes.
Le temps de mesure est de "60 secondes" et l'intervalle de demande de "5 secondes", vous voulez donc accéder au système 12 fois (60÷5) de manière répétée.
1-3. résultat des mesures
En fin de compte, de nombreuses personnes sont intéressées par la conclusion sur les spécifications que le serveur peut gérer et sur la quantité qu'il peut gérer, c'est pourquoi je voudrais énoncer la conclusion en premier.
| CPU: 2core memory: 1GB SSD: 50GB | Jusqu'à 80 demandes simultanées peuvent être traitées |
|---|
Les résultats de cette mesure ont montré ce qui précède. Les résultats ci-dessus permettent de déduire ce qui suit. Essayez d'utiliser ce critère lors du choix des spécifications du serveur.
| CPU: 1core memory: 512MB SSD: 25GB | Jusqu'à 20 demandes simultanées peuvent être traitées. |
|---|---|
| CPU: 2core memory: 1GB SSD: 50GB | Jusqu'à 80 demandes simultanées peuvent être traitées |
| CPU: 3core memory: 2GB SSD: 100GB | Jusqu'à 200 demandes simultanées peuvent être traitées. |
Il a été constaté qu'un système d'une taille d'environ 20 utilisateurs fonctionnerait sans problème avec "CPU : 1core", "mémoire : 512MB" et "SSD : 25GB".
2. Détails des résultats des mesures
Nous avons décrit les résultats des mesures précédemment, mais si vous êtes intéressé par le type de résultats que nous avons décrits, veuillez également consulter les détails des résultats des mesures qui seront décrits ultérieurement.
2-1. Mesures du serveur WEB/AP (Apache, Tomcat)
La requête a été lancée dans un scénario où l'utilisateur se connecte à partir de l'écran de connexion et après s'être connecté, l'écran de liste s'affiche. Par ailleurs, l'écran est construit à l'aide du framework Spring, y compris la fonction d'authentification.
Les mesures ont donné les résultats suivants.
- Pour 10 demandes simultanées⇒OK
- Pour 20 demandes simultanées⇒OK
- Pour 30 demandes simultanées⇒OK
- Pour 40 demandes simultanées⇒OK
- Pour 50 demandes simultanées⇒OK
- Pour 60 demandes simultanées⇒OK
- Pour 70 demandes simultanées⇒OK
- Pour 80 demandes simultanées⇒OK
- Pour 90 demandes simultanées⇒NG
Une erreur s'est produite au 90ème cas. La cause était une erreur de connexion à Apache. L'état du serveur à ce moment-là était le suivant.
- Utilisation du CPU: 26%
- utilisation de la mémoire: 100%
Un manque total de mémoire était le goulot d'étranglement.
Pour ceux qui sont un peu plus geeks, la configuration du module multiprocesseur (MPM) d'Apache est la suivante. MPM s'explique simplement comme le réglage de la quantité de données qu'Apache est autorisé à traiter en parallèle.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestWorkers 250
MaxConnectionsPerChild 0
</IfModule>
Le paramètre qui nous intéresse est "250" pour "MaxRequestWorkers". Il s'agit du nombre maximum de cas qu'Apache peut traiter en même temps. 250", ce qui permet de traiter 250 cas en parallèle au maximum, mais si l'on regarde l'utilisation de la mémoire, environ 8 Mo de mémoire sont utilisés par cas.
Java semblait utiliser 320 Mo de mémoire (248M pour le tas et 72M pour le méta-espace) et Apache 640 Mo de mémoire (8M x 80 processus), et bien que la valeur du paramètre MPM d'Apache soit '250', il semblait ne pas pouvoir créer plus de '80' processus.
Remarque : Le serveur a 1G de mémoire, donc la mémoire totale pour Apache et Java est de 960MB, ce qui est presque à la limite supérieure.
Le serveur AP (côté Java) fonctionnait bien, le goulot d'étranglement était donc le serveur WEB (Apache).
Lorsque Apache et Tomcat sont installés et fonctionnent, nous avons constaté qu'avec les spécifications "CPU : 2core, mémoire : 1GB, SSD : 50GB", le nombre d'accès simultanés "80" est la limite. (L'hypothèse est que les paramètres de mémoire pour Java sont de 248M pour le tas et 72M pour le méta-espace.)
2-2. considération
À partir de là, il faut tenir compte du fait que la mémoire est le goulot d'étranglement. Si la mémoire est modifiée, le nombre de processus pouvant être traités simultanément augmentera également.
(Présent. (memory1GB))
- memory: 1GB
- Nombre de threads Apache: 80 caisses.
- Consommation de mémoire par thread dans Apache.: 8MB
- Consommation de mémoire d'Apache: 640MB(80 caisses.×8MB)
- Consommation de mémoire de Tomcat: 320MB(248 millions pour HEAP., 72m pour le métaspace.)
- Consommation de mémoire d'Apache+Tomcat: 960MB
(après le changement(memory2GB))
- memory: 2GB
- Nombre de threads Apache: 200 cas
- Consommation de mémoire par thread dans Apache.: 8MB
- Consommation de mémoire d'Apache: 1600MB(200 cas×8MB)
- Consommation de mémoire de Tomcat: 320MB(248 millions pour HEAP., 72m pour le métaspace.)
- Consommation de mémoire d'Apache+Tomcat: 1920MB
Avec 2 Go de mémoire, il est possible de traiter 200 cas simultanément. Si la mémoire est augmentée à 3GB, il semble qu'un plus grand nombre de traitements simultanés puisse être effectué, mais le "MaxRequestWorkers (nombre maximum de cas à traiter simultanément)" du MPM d'Apache est "250", donc un réglage ici sera également nécessaire si la mémoire est augmentée davantage. Un réglage de la mémoire Java peut également être nécessaire. A l'inverse, si la mémoire est divisée par deux, on obtient le résultat suivant.
(après le changement(memory512GB))
- memory: 512GB
- Nombre de threads Apache: 20 cas
- Consommation de mémoire par thread dans Apache.: 8MB
- Consommation de mémoire d'Apache: 160MB(20 cas×8MB)
- Consommation de mémoire de Tomcat: 320MB(248 millions pour HEAP., 72m pour le métaspace.)
- Consommation de mémoire d'Apache+Tomcat: 480MB
3. résumé
Les résultats de la mesure du nombre maximum de cas que les serveurs WEB/AP (Apache et Tomcat) peuvent traiter en même temps sont décrits. Il a été constaté qu'un système d'une taille d'environ 20 utilisateurs fonctionnerait sans problème avec "CPU : 1core", "mémoire : 512MB" et "SSD : 25GB".
L'enquête repose sur l'hypothèse qu'aucun autre logiciel ne fonctionne à des performances marginales. Il est recommandé de choisir une spécification avec une certaine marge de manœuvre, car il s'agit d'une valeur marginale.