Einen VPS-Kapazitätstest erstellen, der eine echte Planungsfrage beantwortet
Ein Kapazitätstest ist nützlich, wenn er erklärt, welche Arbeitslast ein Dienst unter festgelegten Bedingungen tragen kann. Anfragen zu senden, bis etwas ausfällt, liefert eine Zahl, doch diese Zahl kann einen unrealistischen Cache-Pfad oder einen gesättigten Lastgenerator beschreiben. Beginnen Sie mit der Entscheidung, die der Test stützen soll, und gestalten Sie Arbeitslast und Messungen darauf aus.
Das Wichtigste in Kürze
Testen Sie repräsentative Arbeit in einer autorisierten Umgebung, messen Sie erfolgreiche Antworten und Latenzverteilungen gemeinsam, identifizieren Sie die begrenzende Schicht und bewahren Sie die Bedingungen zusammen mit dem Ergebnis auf.
Formulieren Sie die Entscheidung, bevor Sie den Test aufbauen
Legen Sie fest, was sich ändert und was die Anwendung weiterhin leisten muss. Eine bevorstehende Kampagne kann das Browsing erhöhen, während ein Importjob mit normalem API-Traffic konkurriert. Eine Ressourcenänderung kann darauf abzielen, Antwortzeiten während eines bestehenden Peaks zu senken. Benennen Sie die wichtige User Journey und ihr akzeptables Verhalten. Vermeiden Sie es, mit einer willkürlichen Anfragenzahl zu beginnen, die keinen Bezug dazu hat, wie Menschen oder Hintergrundprozesse den Dienst nutzen.
Erfassen Sie die aktuelle Anwendungsversion, Datenbankgröße, Region, Hosting-Ressourcen und relevante Konfiguration. Beziehen Sie Caching, Worker-Limits und externe Abhängigkeiten ein. So wird das Ergebnis für andere Maintainer wiederholbar. Wenn ein späterer Lauf mehrere dieser Punkte gleichzeitig ändert, kennzeichnen Sie ihn als anderes Szenario, statt ihn als Beleg dafür darzustellen, dass ein zusätzlicher CPU alles gelöst hat. Halten Sie Test-Zugangsdaten von echten Kundenkonten getrennt.
Nutzen Sie eine Staging- oder anderweitig kontrollierte Umgebung mit ausdrücklicher Genehmigung und einem geeigneten Zeitfenster. Stimmen Sie sich mit dem Team ab, wenn der Test gemeinsam genutzte Infrastruktur oder Dienstlimits beeinflussen könnte. Ersetzen Sie externe Zahlungs-, E-Mail- und andere Drittanbieter-Aktionen durch geeignete Testintegrationen, sofern keine Teilnahme vereinbart ist. Eine Kapazitätsübung sollte keine echten Käufe auslösen, keine große Nachrichtenmenge versenden und nicht zu einer unangekündigten Traffic-Flut gegen einen anderen Dienst werden.
Modellieren Sie die Anwendungsarbeit statt einer attraktiven Schlagzeile
Wählen Sie eine realistische Mischung aus Anfragen und Besucherzuständen. Öffentliche gecachte Seiten, authentifizierte APIs, Uploads und aufwendige Suchen können sehr unterschiedliche Kosten haben. Fügen Sie geeignete Pausen oder ein Ankunftsmuster ein, das zur Planungsfrage passt. Ein Test, der wiederholt dieselbe kleine gecachte Antwort anfordert, kann helfen, diesen Pfad zu prüfen, belegt aber nicht die Kapazität von Kontoseiten oder Datenbankschreibvorgängen. Erläutern Sie diese Einschränkung zusammen mit dem Ergebnis.
| Szenario | Was es beantwortet | Was es nicht belegt |
|---|---|---|
| Warme öffentliche Seite | Verhalten eines wiederverwendbaren Antwortpfads | Personalisierte Anwendungskapazität |
| Angemeldete API-User-Journey | Die ausgewählte Anwendungs- und Datenbankarbeit | Jeder mögliche Endpunkt oder Kundenverlauf |
| Geplanter Job plus normale Anfragen | Konkurrenz während dieser bekannten Überschneidung | Zukünftige Jobs mit anderen Daten |
| Schrittweise steigende Ankünfte | Wo Latenz und Fehler zu steigen beginnen | Ein universelles Maximum für die Hosting-Reihe |
Befüllen Sie den Test mit repräsentativen Datenverteilungen. Eine Produktliste mit wenigen Zeilen kann ein anderes Abfrageverhalten auslösen als eine mit langer Historie. Verwenden Sie synthetische oder ordnungsgemäß geschützte Daten und bestätigen Sie, dass Reset- und Bereinigungsverfahren vor dem Hauptlauf funktionieren. Beobachten Sie neben der Anwendung auch CPU, Netzwerk und Scheduling des Lastgenerators. Andernfalls kann ein Engpass im Generator einen Server stabil erscheinen lassen, nur weil die beabsichtigte Arbeit nie ankam.
Messen Sie abgeschlossene Vorgänge und legen Sie fest, wann der Test beendet wird
Verfolgen Sie die Rate erfolgreich abgeschlossener Vorgänge, Fehler und Latenzverteilungen gemeinsam. Ein Durchschnitt kann ungewöhnlich langsame Antworten verbergen, während eine hohe Anfrage rate Antworten enthalten kann, die die User Journey scheitern lassen. Prüfen Sie gegebenenfalls Antwortinhalte oder Anwendungsergebnisse, statt jede HTTP-Antwort als Erfolg zu werten. Trennen Sie die Zeit für den Verbindungsaufbau von der Wartezeit der Anwendung und der Übertragungszeit, wenn die Tools dies zulassen. Vergleichen Sie diese Beobachtungen mit Server- und Datenbankmessungen aus demselben Zeitraum.
Definieren Sie Abbruchbedingungen, bevor Sie den Test ausführen. Dazu können anhaltende Fehler, inakzeptable Latenz, übermäßiger Ressourcendruck oder ein Signal gehören, dass ein anderes System beeinträchtigt wird. Wählen Sie Werte, die zur tatsächlichen Anwendung und Umgebung passen; es gibt keinen universellen Schwellenwert, der belegt, dass jeder Dienst gesund ist. Automatisierte Schwellenwerte können helfen, einen Lauf zu bewerten, aber jemand muss weiterhin die Verantwortung für den Test, seine Auswirkungen und die Entscheidung zum Stoppen tragen.
Steigern Sie die Arbeit in Stufen, damit Sie die Veränderung beobachten können, statt sofort zu einem Extremwert zu springen. Halten Sie eine stabile Phase lange genug, um das für die Arbeitslast relevante Verhalten zu sehen, einschließlich bekannter Queue- oder Cache-Effekte. Notieren Sie, wann der Test beginnt und wann sich die einzelnen Stufen ändern. Wenn die Latenz steigt, während CPU niedrig bleibt, untersuchen Sie Wartezeiten, Konkurrenz und Abhängigkeiten, bevor Sie schlussfolgern, dass der Plan mehr Kerne benötigt.
Das Ergebnis in einen kontrollierten nächsten Schritt überführen
- Workload-Definition, Datenannahmen und Softwareversionen speichern.
- Berichten Sie die Anzahl erfolgreicher Vorgänge pro Sekunde, die Fehlerrate und die Latenz-Perzentile gemeinsam.
- Die wahrscheinlich begrenzende Schicht und die sie stützenden Belege identifizieren.
- Eine relevante Einstellung oder Ressource ändern und dasselbe Szenario wiederholen.
- Den verbleibenden Spielraum und die Grenzen der Schlussfolgerung dokumentieren.
Beispielsweise kann eine API gewöhnliche Lesezugriffe problemlos bewältigen, aber eine lange Warteschlange bilden, wenn ein geplanter Export mit ihnen zeitlich zusammenfällt. Die sinnvolle Reaktion kann darin bestehen, den Export neu zu planen oder umzugestalten, die Transaktionsdauer zu verkürzen oder die passende Ressource anzupassen. Eine größere Hosting-Konfiguration ist eine mögliche Maßnahme, nicht das einzige Ergebnis. Prüfen Sie nach einer Änderung erneut den gesamten Anwendungsablauf, damit schnellere Antworten nicht fehlerhafte oder fehlende Arbeit verschleiern.
Verknüpfen Sie Ergebnisse bei der Wahl eines VPS mit ihren Bedingungen. Ein virtueller Kern, eine Speicherzuweisung und ein Netzwerkport beschreiben Ressourcen; sie garantieren keine feste Anzahl an Besuchern oder Anfragen für jede Anwendung. Wiederholen Sie den Test nach wesentlichen Änderungen an Code, Daten oder Verkehrsmix. Kapazitätsplanung wird verlässlicher, wenn sie ein wiederholter Vergleich mit dokumentierten Annahmen ist und nicht eine einzelne beeindruckende Zahl, losgelöst vom System, das sie erzeugt hat.
