J'ai mesuré le nombre maximum de serveurs WEB/AP (Apache et Tomcat) pouvant être gérés en même temps en utilisant un serveur de location VPS.


Date de publication:1er janvier 2021.



INFOMARTION > J'ai mesuré le nombre maximum de serveurs WEB/AP (Apache et Tomcat) pouvant être gérés en même temps en utilisant un serveur de location VPS.

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.

J'ai mesuré le nombre maximum de cas que le serveur web (Apache) peut traiter simultanément en utilisant un serveur de location VPS.

Table des matières

  1. mesure
  2. Détails des résultats des mesures
  3. résumé

1. mesure

1-1. Environnement de mesure

Voici l'environnement dans lequel les mesures seront effectuées.

■Informations sur le serveur de location

CPU2core
memory1GB
SSD50GB

■Informations sur le serveur

OSCentOS 7.4 64bit
Serveur webApache HTTP Server 2.4.41
Serveur APApache Tomcat 9.0.27
Serveur de base de donnéesPostgreSQL 10.2
JavaOpenJDK 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.
※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.

Merci d'avoir regardé jusqu'à la fin.