Apache-Lasttest auf einem kleinen VPS
Datum der Veröffentlichung：
Aktualisiert:
Fachartikel > Apache-Lasttest auf einem kleinen VPS
Status 2026 und sichere Verwendung
Schlussfolgerung: In diesem Artikel wird ein VPS-Experiment beschrieben, kein universelles Apache-Parallelitätslimit. Die Kapazität hängt von der Antwortarbeit, MPM, Worker-Limits, Keep-Alive, TLS, CPU, Arbeitsspeicher, Speicher, Netzwerk, Client-Platzierung und dem Latenzziel ab, das Sie als akzeptabel definieren.
Was Sie lernen werden
- Wie der ursprüngliche Test aufgebaut war und was seine beobachteten Zahlen zeigen – und was nicht.
- Welche Apache- und Betriebssystemmetriken helfen, den ersten Engpass zu identifizieren?
- So entwerfen Sie einen wiederholbaren Lasttest mit Aufwärmphase, Perzentilen, Fehlern und serverseitiger Telemetrie.
Für wen ist dies gedacht: Ingenieure, die ein First-Pass-Webserver-Experiment auf einem kleinen VPS planen.
Stand 2026: Die folgenden Messungen stammen aus der ursprünglichen Umgebung des Autors und wurden für dieses Update nicht erneut ausgeführt. Verwenden Sie sie nicht als aktuellen Anbieter-Benchmark oder als Empfehlung zur Produktionsgröße. Testen Sie Ihre eigene Anwendung und Fehlerschwellenwerte.
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 ein Apache-Server in der Umgebung des Autors verarbeitete. Die Ergebnisse sind eine Fallstudie und keine aktuelle Empfehlung zur VPS-Dimensionierung.
Dieses Mal wurden die Messungen nur auf dem WEB-Server (Apache) durchgeführt. Für Messungen auf den WEB/AP-Servern (Apache und Tomcat) lesen Sie bitte den folgenden Artikel.
Apache und Tomcat auf einem VPS: Lasttest und Engpässe
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 |
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 | Es können bis zu 120 gleichzeitige Anfragen 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 60 gleichzeitige Anfragen bearbeitet werden. |
|---|---|
| CPU：2core memory：1GB SSD：50GB | Es können bis zu 120 gleichzeitige Anfragen bearbeitet werden. |
| CPU：3core memory：2GB SSD：100GB | Es können bis zu 240 gleichzeitige Anfragen bearbeitet werden. |
In diesem konkreten Benchmark mit statischen Seiten bewältigte die Umgebung mit 1 CPU-Kern, 512 MB Arbeitsspeicher und 25 GB SSD die getestete Last. Daraus lässt sich keine unterstützte Benutzerzahl ableiten.
2. Details der Messergebnisse
Die folgenden Abschnitte dokumentieren Bedingungen und Ergebnisse, damit der begrenzte Geltungsbereich der Zahlen nachvollziehbar bleibt.
2-1. WEB-Server (Apache) Messungen
Wiederholte Anfragen wurden gegen in HTML erstellte Seiten gestellt. Es handelt sich um eine einfache Seite ohne komplexe PHP-Verarbeitung oder JavaScript.
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⇒OK
- Für 100 gleichzeitige Anfragen⇒OK
- 110 gleichzeitige Anfragen⇒OK
- Für 120 gleichzeitige Anfragen⇒OK
- Für 130 gleichzeitige Anfragen⇒NG
Beim 130. Fall ist ein Fehler aufgetreten. Die Ursache war ein Verbindungsfehler zum Apache. Der Zustand des Servers war zu diesem Zeitpunkt wie folgt.
- CPU-Auslastung: 26%
- Speicherverbrauchsrate: 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.
Es schien 960 MB Speicher zu verbrauchen (8M x 120 Prozesse) und der Einstellungswert war '250', aber es schien, dass es nicht möglich war, mehr als '120' Prozesse zu erstellen.
Hinweis: Der Arbeitsspeicher des Servers ist fast bis zu seiner Grenze von 1 GB ausgelastet.
Beim tatsächlichen Betrieb des Servers, wenn PHP und Java mit einbezogen werden, liegt die Grenze bei etwa 100 Fällen, und wenn Platz vorhanden ist, können 80 Fälle gleichzeitig parallel bearbeitet werden.
Wenn nur Apache installiert ist und läuft, mit den Spezifikationen "CPU: 2core, Arbeitsspeicher: 1GB, SSD: 50GB", wurde die Anzahl der gleichzeitigen Zugriffe "120" als Limit ermittelt.
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：120 Fälle
- Speicherverbrauch pro Thread im Apache：8MB
- Apache-Speicherverbrauch：960MB（120 Fälle×8MB）
【nach der Änderung（memory2GB）】
- memory：2GB
- Anzahl der Apache-Threads：240 Fälle.
- Speicherverbrauch pro Thread im Apache：8MB
- Apache-Speicherverbrauch：1920MB（240 Fälle.×8MB）
Wenn der Arbeitsspeicher auf 2 GB erhöht wird, kann die Anzahl der Fälle auf etwa 240 gleichzeitig verdoppelt werden. Wenn der Arbeitsspeicher auf 3 GB erhöht wird, scheint mehr gleichzeitige Verarbeitung möglich zu sein, aber die "MaxRequestWorkers (maximale Anzahl von gleichzeitig zu verarbeitenden Fällen)" des Apache MPM ist "250", so dass auch hier eine Anpassung erforderlich ist, wenn der Arbeitsspeicher weiter erhöht wird. 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：60 Fälle.
- Speicherverbrauch pro Thread im Apache：8MB
- Apache-Speicherverbrauch：480MB（60 Fälle.×8MB）
3. Zusammenfassung
Der Artikel dokumentiert einen Apache-Test mit gleichzeitigen Anfragen unter festgelegten Bedingungen. Eine Kapazitätsplanung muss außerdem reale Antworten, TLS, Lastspitzen, Clientverhalten und akzeptable Latenzen berücksichtigen; eine feste Benutzerzahl lässt sich aus diesem Lauf nicht ableiten.
Die Erhebung 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.