Ich habe die maximale Anzahl von WEB/AP-Servern (Apache und Tomcat) gemessen, die gleichzeitig mit einem VPS-Mietserver arbeiten können.


Datum der Veröffentlichung:1. Januar 2021.



INFOMARTION > Ich habe die maximale Anzahl von WEB/AP-Servern (Apache und Tomcat) gemessen, die gleichzeitig mit einem VPS-Mietserver arbeiten können.

Überblick.

Ich habe die maximale Anzahl von Fällen gemessen, die die WEB/AP-Server (Apache und Tomcat) gleichzeitig verarbeiten können, und ich möchte über die Ergebnisse schreiben. Wir waren neugierig, wie viele Anfragen maximal bedient werden können, und haben daher eine Umfrage durchgeführt. Verwenden Sie dies als Referenz für die Auswahl der VPS-Server-Spezifikationen.

Dieses Mal wurden die Messungen auf den WEB/AP-Servern (Apache und Tomcat) durchgeführt, aber bitte lesen Sie den Artikel unten für Messungen nur auf dem WEB-Server (Apache).

Ich habe die maximale Anzahl von Fällen gemessen, die der Webserver (Apache) mit einem VPS-Mietserver gleichzeitig verarbeiten kann.

Inhaltsübersicht

  1. Messung
  2. Details der Messergebnisse
  3. Zusammenfassung

1. Messung

1-1. Messumgebung

Im Folgenden wird die Umgebung beschrieben, in der die Messungen durchgeführt werden.

■Informationen zum Mietserver

CPU2core
memory1GB
SSD50GB

■Server-Informationen

OSCentOS 7.4 64bit
WebserverApache HTTP Server 2.4.41
AP-ServerApache Tomcat 9.0.27
DB-ServerPostgreSQL 10.2
JavaOpenJDK 11

1-2. Messverfahren

Ich würde dies gerne mit JMeter messen. JMeter ist ein Tool zur Lastmessung, das in Java läuft. Mit diesem Tool kann eine große Anzahl von Anfragen gleichzeitig gestellt werden. Wir möchten die Anzahl der gleichzeitigen Anfragen mit JMeter schrittweise erhöhen und die Last steigern, bis die Verarbeitung nicht mehr zu bewältigen ist.

Zu den besonderen Bedingungen gehören.

  • Abfragezeitraum・・・5 Sek.
  • Anzahl der gleichzeitigen Anfragen・・・10 Fälle.(Die Messungen wurden schrittweise um jeweils 10 Fälle erhöht.)
  • Messung der Zeit・・・60 Sekunden.

Die Messzeit beträgt "60 Sekunden" und das Abfrageintervall "5 Sekunden", Sie wollen also 12 Mal (60÷5) wiederholt auf das System zugreifen.

1-3. Messergebnis

Letztendlich sind viele Leute an der Schlussfolgerung interessiert, welche Spezifikationen der Server bewältigen kann und wie viel er bewältigen kann, daher möchte ich die Schlussfolgerung zuerst nennen.

CPU:2core
memory:1GB
SSD:50GB
Bis zu 80 gleichzeitige Anfragen können bearbeitet werden

Die Ergebnisse dieser Messung zeigen das oben Gesagte. Aus den oben genannten Ergebnissen lässt sich Folgendes ableiten. Versuchen Sie, dies als Kriterium bei der Auswahl der Serverspezifikationen zu verwenden.

CPU:1core
memory:512MB
SSD:25GB
Es können bis zu 20 gleichzeitige Anfragen bearbeitet werden.
CPU:2core
memory:1GB
SSD:50GB
Bis zu 80 gleichzeitige Anfragen können bearbeitet werden
CPU:3core
memory:2GB
SSD:100GB
Es können bis zu 200 gleichzeitige Anfragen bearbeitet werden.

Es wurde festgestellt, dass ein System mit einer Größe von etwa 20 Benutzern mit "CPU: 1core", "Speicher: 512MB" und "SSD: 25GB" problemlos funktioniert.

2. Details der Messergebnisse

Wir haben die Messergebnisse bereits beschrieben, aber wenn Sie daran interessiert sind, welche Art von Ergebnissen wir beschrieben haben, lesen Sie bitte auch die Details zu den Messergebnissen, die in Zukunft beschrieben werden.

2-1. WEB/AP-Server (Apache, Tomcat) Messungen

Die Anforderung wurde in einem Szenario ausgelöst, in dem sich der Benutzer über den Anmeldebildschirm anmeldet und nach der Anmeldung der Listenbildschirm angezeigt wird. Der Bildschirm ist übrigens mit dem Spring-Framework aufgebaut, einschließlich der Authentifizierungsfunktion.

Die Messungen ergaben die folgenden Ergebnisse.

  • Für 10 gleichzeitige Anfragen⇒OK
  • Für 20 gleichzeitige Anfragen⇒OK
  • Für 30 gleichzeitige Anfragen⇒OK
  • Für 40 gleichzeitige Anfragen⇒OK
  • Für 50 gleichzeitige Anfragen⇒OK
  • Für 60 gleichzeitige Anfragen⇒OK
  • Für 70 gleichzeitige Anfragen⇒OK
  • Für 80 gleichzeitige Anfragen⇒OK
  • Für 90 gleichzeitige Anfragen⇒NG

Der Fehler trat beim 90. Fall auf. Die Ursache war ein Verbindungsfehler zum Apache. Der Zustand des Servers war zu diesem Zeitpunkt wie folgt.

  • CPU-Auslastung・・・26%
  • Speicherauslastung・・・100%

Ein völliger Mangel an Speicherplatz war der Engpass.

Für diejenigen, die es etwas komplizierter mögen, sieht die Konfiguration des Apache Multi-Processing Module (MPM) wie folgt aus. MPM wird einfach als die Einstellung erklärt, wie viel der Apache parallel verarbeiten darf.

<IfModule mpm_prefork_module>
    StartServers             5
    MinSpareServers          5
    MaxSpareServers         10
    MaxRequestWorkers      250
    MaxConnectionsPerChild   0
</IfModule>

Die interessante Einstellung ist "250" für "MaxRequestWorkers". Dies ist eine Einstellung für die maximale Anzahl von Fällen, die Apache gleichzeitig bearbeiten kann. 250', so dass 250 Fälle maximal parallel verarbeitet werden konnten, aber wenn man den Speicherverbrauch betrachtet, wurden pro Fall etwa 8 MB Speicher verbraucht.

Java schien 320 MB Arbeitsspeicher (248 MB für Heap und 72 MB für Metaspace) und der Apache 640 MB Arbeitsspeicher (8 MB x 80 Prozesse) zu verbrauchen, und obwohl der MPM-Einstellungswert des Apache "250" ist, konnte er anscheinend nicht mehr als "80" Prozesse erstellen.
※Der Server verfügt über 1 GB Arbeitsspeicher, so dass der Gesamtspeicher für Apache und Java 960 MB beträgt, was fast an der Obergrenze liegt.

Der AP-Server (Java-Seite) funktionierte einwandfrei, der Engpass war also der WEB-Server (Apache).

Wenn Apache und Tomcat installiert sind und laufen, haben wir festgestellt, dass bei den Spezifikationen "CPU: 2core, Speicher: 1GB, SSD: 50GB" die Anzahl der gleichzeitigen Zugriffe "80" ist.(Die Annahme ist, dass die Speichereinstellungen für Java 248M für Heap und 72M für Metaspace sind.)

2-2. Berücksichtigung

Da der Speicher der Engpass ist, erhöht sich bei einer Änderung des Speichers die Anzahl der Prozesse, die gleichzeitig verarbeitet werden können.

【Anwesend.(memory1GB)】

  • memory:1GB
  • Anzahl der Apache-Threads:80 Fälle.
  • Speicherverbrauch pro Thread im Apache.:8MB
  • Apache-Speicherverbrauch:640MB(80 Fälle.×8MB)
  • Tomcat-Speicherverbrauch:320MB(248 Millionen für HEAP.、72m für Metaspace.)
  • Speicherverbrauch von Apache+Tomcat:960MB

【nach der Änderung(memory2GB)】

  • memory:2GB
  • Anzahl der Apache-Threads:200 Fälle
  • Speicherverbrauch pro Thread im Apache.:8MB
  • Apache-Speicherverbrauch:1600MB(200 Fälle×8MB)
  • Tomcat-Speicherverbrauch:320MB(248 Millionen für HEAP.、72m für Metaspace.)
  • Speicherverbrauch von Apache+Tomcat:1920MB

Mit 2 GB Speicher können möglicherweise 200 Fälle gleichzeitig bearbeitet werden. Wenn der Arbeitsspeicher auf 3 GB erhöht wird, scheint mehr gleichzeitige Verarbeitung möglich zu sein, aber die "MaxRequestWorkers (maximale Anzahl der gleichzeitig zu verarbeitenden Fälle)" des Apache MPM ist "250", so dass auch hier eine Anpassung erforderlich ist, wenn der Arbeitsspeicher weiter erhöht wird. Auch eine Java-Speicheroptimierung kann erforderlich sein. Im umgekehrten Fall, wenn der Speicher um die Hälfte reduziert wird, sieht es folgendermaßen aus.

【nach der Änderung(memory512GB)】

  • memory:512GB
  • Anzahl der Apache-Threads:20 Fälle
  • Speicherverbrauch pro Thread im Apache.:8MB
  • Apache-Speicherverbrauch:160MB(20 Fälle×8MB)
  • Tomcat-Speicherverbrauch:320MB(248 Millionen für HEAP.、72m für Metaspace.)
  • Speicherverbrauch von Apache+Tomcat:480MB

3. Zusammenfassung

Die Ergebnisse der Messung der maximalen Anzahl von Fällen, die die WEB/AP-Server (Apache und Tomcat) gleichzeitig verarbeiten können, werden beschrieben. Es wurde festgestellt, dass ein System mit einer Größe von etwa 20 Benutzern mit "CPU: 1core", "Speicher: 512MB" und "SSD: 25GB" problemlos funktioniert.

Die Umfrage basiert auf der Annahme, dass keine andere Software mit marginaler Leistung läuft. Es wird empfohlen, eine Spezifikation mit etwas Spielraum zu wählen, da es sich um einen marginalen Wert handelt.

Danke, dass Sie bis zum Ende zugesehen haben.