Apache und Tomcat auf einem VPS: Lasttest und Engpässe
Datum der Veröffentlichung：
Aktualisiert:
Fachartikel > Apache und Tomcat auf einem VPS: Lasttest und Engpässe
Status 2026 und sichere Verwendung
Schlussfolgerung: In einem Apache-zu-Tomcat-Stack kann die erste Grenze der Client, Proxy-Worker, Connector-Threads, JVM-Heap oder Garbage Collection, Anwendungscode, Datenbank oder VPS selbst sein. Eine einzelne Parallelitätszahl kann die Kapazität ohne Latenz-, Fehler- und Ressourcennachweise nicht identifizieren.
Was Sie lernen werden
- Was beim ursprünglichen zweistufigen VPS-Experiment gemessen wurde.
- Wie Proxy- und Tomcat-Connector-Beschränkungen mit der Antwortzeit der Anwendung interagieren.
- Was in einem modernen Test aufgezeichnet werden soll: Perzentile, Durchsatz, Fehler, CPU, Speicher, GC, Threads und Downstream-Sättigung.
Für wen ist das gedacht: Java-Webteams lernen, wie man einen kleinen, evidenzbasierten Kapazitätstest entwirft.
Stand 2026: Die folgenden Ergebnisse gehören zum Originaltest des Autors und wurden für dieses redaktionelle Update nicht reproduziert. Betrachten Sie sie als Fallstudie, nicht als verifizierte aktuelle Leistung oder als VPS-Kaufempfehlung.
Sicherheitshinweis: Die Befehle und Konfigurationsbeispiele im Originalartikel wurden nicht in einer aktuellen Produktionsumgebung erneut ausgeführt. Überprüfen Sie unterstützte Versionen, Backups, Zugriffskontrollen und Rollback-Schritte in einer separaten Testumgebung, bevor Sie sie anwenden.
Offizielle Primärquellen
Überblick
Dieser historische Test erfasst die gleichzeitigen Anfragen, die Apache und Tomcat in der Umgebung des Autors verarbeiteten. Die Ergebnisse sind eine Fallstudie und keine aktuelle Empfehlung zur VPS-Dimensionierung.
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).
Apache-Lasttest auf einem kleinen VPS
Inhaltsübersicht
1. Messung
1-1. Messumgebung
Im Folgenden wird die Umgebung beschrieben, in der die Messungen durchgeführt werden.
■Informationen zum Mietserver
| CPU | 2core |
|---|---|
| memory | 1GB |
| SSD | 50GB |
■Server-Informationen
| OS | CentOS 7.4 64bit |
|---|---|
| Webserver | Apache HTTP Server 2.4.41 |
| AP-Server | Apache Tomcat 9.0.27 |
| DB-Server | PostgreSQL 10.2 |
| Java | OpenJDK 11 |
1-2. Messverfahren
Der Test verwendet JMeter, ein Java-basiertes Lasttestwerkzeug. Die Zahl gleichzeitiger Anfragen wird erhöht, bis der Server die Last nicht mehr bewältigt.
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
Die Ergebnisse stehen zuerst; sie gelten ausschließlich für die beschriebene Testumgebung.
| 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. |
In diesem konkreten Apache-/Tomcat-Benchmark bewältigte die Umgebung mit 1 CPU-Kern, 512 MB Arbeitsspeicher und 25 GB SSD die getestete Last. Das belegt keine Kapazität für 20 gleichzeitige oder registrierte Benutzer in einer Produktionsumgebung.
2. Details der Messergebnisse
Die folgenden Abschnitte dokumentieren Bedingungen und Ergebnisse, damit der begrenzte Geltungsbereich der Zahlen nachvollziehbar bleibt.
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.
Hinweis: 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.
In diesem Test erreichte zuerst die Apache-Seite ihre Grenze. Das beschreibt nur den Engpass dieser Konfiguration und Last, nicht anderer Umgebungen.
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
Der Artikel dokumentiert gleichzeitige Anfragen an Apache und Tomcat unter festgelegten Bedingungen. Für die Kapazitätsplanung müssen reale Geschäftslogik, Datenbankzugriffe, TLS, Lastspitzen und akzeptable Latenzen einbezogen werden; eine feste Benutzerzahl lässt sich aus diesem Lauf nicht ableiten.
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.