Durchsatz und Parallelitätsgrenze durch einen Proxy in k6 und JMeter messen

Bei der Arbeit über einen Proxy stellt sich fast immer die eine Frage: Wie viele parallele Anfragen kann die Verbindung aus „Ihrem Client – Proxy – Zielserver“ wirklich verkraften, bevor die Latenzen in die Höhe schnellen und Fehler auftreten? Diese Anleitung zeigt Ihnen, wie Sie das im Voraus messen – und nicht erst bei einer großen Auslastung, wenn die Stunden im Stillstand zählen.

Einleitung: Warum die Grenze vorher kennen, statt bei einer großen Auslastung

Stellen Sie sich eine typische Situation vor. Sie starten eine große Aufgabe zum Sammeln öffentlicher Daten über einen Proxy-Pool. In den ersten tausend Anfragen läuft alles gut, doch dann steigen die Latenzen, ein Teil der Anfragen scheitert mit Timeouts, und Sie wissen nicht: Liegt es an Ihrem Code, am Proxy oder am Zielserver? Zu diesem Zeitpunkt haben Sie bereits Zeit und möglicherweise Daten verloren.

Viel sinnvoller ist es, vorab einen kontrollierten Lasttest durchzuführen und den Punkt der Degradation zu finden. Dann können Sie eine sichere Anzahl an Threads wählen und die Auslastungszeit richtig planen.

Was der Leser am Ende erhält

Nach Abschluss dieser Anleitung können Sie selbstständig:

• Ein korrektes Lastszenario in k6 erstellen und über einen Proxy ausführen.
• Dasselbe Szenario in JMeter mit Proxy-Konfiguration im Testplan wiederholen.
• Berichte lesen: RPS (Anfragen pro Sekunde), Perzentil-Latenzen und Fehlerquote verstehen.
• Die Grenze des Proxys von der Grenze Ihres Clients und der des Zielservers unterscheiden.
• Ergebnisse in Thread-Anzahl, Pool-Größe und erwartete Auslastungszeit umrechnen.

Für wen diese Anleitung gedacht ist

Das Material richtet sich an Ingenieure, Datenanalysten und Entwickler mit mittlerer Erfahrung. Wenn Sie bereits einfache Skripte in JavaScript geschrieben oder Programme über die Kommandozeile gestartet haben, werden Sie sich wohlfühlen. Für Anfänger erklären wir jeden Begriff in einfachen Worten.

Was Sie im Voraus wissen sollten

Grundlegende Fähigkeiten genügen: ein Terminal öffnen, ein Programm installieren und eine Textdatei bearbeiten. Grundkenntnisse über HTTP auf dem Niveau „Was ist eine Anfrage und eine Antwort“ sind ein Plus, aber nicht notwendig.

Wie viel Zeit Sie benötigen

Für die Installation der Tools benötigen Sie etwa 30–40 Minuten. Den ersten funktionierenden Test in k6 starten Sie innerhalb einer Stunde. Der vollständige Zyklus mit JMeter und Analyse dauert 3–4 Stunden entspannte Arbeit.

⚠️ Achtung: Alle Beispiele in dieser Anleitung dienen dem Testen Ihres eigenen Testsystems oder von Ressourcen, für die Sie ausdrücklich die Erlaubnis zur Belastung haben. Belastungstests fremder Dienste ohne Zustimmung sind nicht zulässig. Über Ethik sprechen wir am Ende gesondert.

Vorbereitung: Tools, Anforderungen und Zugänge

Bevor Sie messen, müssen Sie die Arbeitsumgebung einrichten. Hier listen wir alles Notwendige auf und zeigen, wie Sie jede Komponente installieren.

Notwendige Tools und Zugänge

• k6 – leichtgewichtiges Tool für Lasttests, Szenarien werden in JavaScript geschrieben.
• Apache JMeter – klassisches Tool mit grafischer Oberfläche auf Java-Basis.
• Java 17 oder neuer – erforderlich für JMeter.
• Zugang zu einem Proxy von Proxeon: Adresse, Port, Benutzername und Passwort. Diese Daten erhalten Sie im persönlichen Konto des Dienstes.
• Testziel – Ihr eigenes Testsystem oder eine freigegebene Ressource.

Systemanforderungen

Für komfortables Arbeiten reicht ein Rechner mit 4 Prozessorkernen und 8 GB RAM. Für hohe Last (tausende virtuelle Benutzer) empfehlen sich 8 Kerne und 16 GB. Das Betriebssystem kann Windows, macOS oder Linux sein, alle Tools sind plattformübergreifend.

Tipp: Starten Sie den Lastgenerator auf einem separaten Rechner oder in einem separaten Cloud-Server. So vermeiden Sie, dass die Last auf Ihrem Laptop mit der Last auf dem Proxy verwechselt wird.

k6 installieren

1. Öffnen Sie die offizielle Installationsmethode für Ihr System: auf macOS über den Paketmanager Homebrew mit dem Befehl brew install k6.
2. Unter Windows verwenden Sie den Paketmanager Chocolatey: choco install k6.
3. Unter Linux laden Sie das Paket aus dem Repository des Projekts herunter und installieren es über den Systempaketmanager.
4. Überprüfen Sie die Installation mit dem Befehl k6 version – Sie sehen die Versionsnummer.

✅ Überprüfung: Wenn der Befehl k6 version eine Zeile mit Versionsnummer ausgibt und keinen Fehler „Befehl nicht gefunden“ anzeigt, ist das Tool korrekt installiert.

Java und JMeter installieren

1. Installieren Sie OpenJDK in Version 17 oder neuer und überprüfen Sie mit dem Befehl java -version.
2. Laden Sie das Archiv Apache JMeter von der offiziellen Projektwebsite im Download-Bereich herunter.
3. Entpacken Sie das Archiv in einen geeigneten Ordner, z. B. in Ihr Home-Verzeichnis.
4. Navigieren Sie zum Unterordner bin im entpackten JMeter.
5. Starten Sie die Datei jmeter (unter Linux und macOS) oder jmeter.bat (unter Windows).
6. Warten Sie, bis das grafische Fenster mit dem Testplan-Baum auf der linken Seite erscheint.

✅ Überprüfung: Wenn sich das JMeter-Fenster geöffnet hat und im linken Baum das Element „Test Plan“ angezeigt wird, ist alles bereit.

Sicherungskopien und Vorbereitung des Testsystems

Wenn Sie Ihren eigenen Dienst testen, erstellen Sie im Voraus einen Snapshot oder ein Backup der Testdaten. Die Last darf die Produktion nicht beschädigen. Verwenden Sie nach Möglichkeit eine Kopie der Umgebung statt des Live-Servers.

Grundbegriffe einfach erklärt

Um Berichte zu lesen und Begriffe nicht zu verwechseln, erläutern wir die wichtigsten Konzepte.

Durchsatz und RPS

Durchsatz – wie viel nützliche Arbeit das System pro Zeiteinheit leistet. Im HTTP-Kontext wird er meist in RPS (Anfragen pro Sekunde) gemessen. Je höher der RPS bei akzeptabler Latenz, desto besser.

Latenz und Perzentile

Latenz – die Zeit vom Senden der Anfrage bis zum Erhalt der Antwort. Ein einzelner Durchschnittswert ist irreführend, da seltene langsame Anfragen darin untergehen. Daher verwendet man Perzentile.

Das Perzentil p95 bedeutet: 95 Prozent der Anfragen waren schneller als dieser Wert, 5 Prozent langsamer. Das Perzentil p99 zeigt das Verhalten der langsamsten Anfragen. Gerade p95 und p99 bilden die reale Erfahrung unter Last am besten ab.

Fehlerquote und Degradationspunkt

Fehlerquote – der Prozentsatz der Anfragen, die nicht erfolgreich waren: Timeouts, Verbindungsabbrüche, Antwortcodes 5xx. Degradationspunkt – der Moment, in dem steigende Last den RPS nicht mehr erhöht, dafür aber Latenzen und Fehler stark ansteigen. Das ist die gesuchte Grenze.

Parallelität und virtuelle Benutzer

Parallelität – wie viele Anfragen gleichzeitig ausgeführt werden. In k6 wird sie über VU (virtual users, virtuelle Benutzer) definiert, in JMeter über die Thread-Anzahl in der Thread Group. Ein VU oder Thread sendet Anfragen sequenziell, viele zusammen erzeugen parallele Last.

Proxy in der Lastkette

Ein Proxy ist ein Zwischenknoten, über den Ihre Anfragen laufen. Er hat seine eigene Grenze für gleichzeitige Verbindungen und Durchsatz. Unser Ziel ist herauszufinden, ab welcher Parallelitätsstufe dieser Knoten zum Engpass wird.

Tipp: Behalten Sie Littles Gesetz im Kopf: Die durchschnittliche Anzahl gleichzeitiger Anfragen entspricht ungefähr dem RPS multipliziert mit der durchschnittlichen Latenz in Sekunden. Das hilft, die benötigte Parallelität schnell abzuschätzen.

Schritt 1: Testziel und Proxy-Daten vorbereiten

Ziel dieses Schritts: Eine funktionierende Zieladresse und eine korrekt formatierte Proxy-Verbindungszeichenfolge erhalten.

1. Bestimmen Sie die Ziel-URL, die Sie belasten möchten. Nehmen wir an, es ist Ihr Testsystem, z. B. eine Adresse wie https://stend.local/api/health.
2. Stellen Sie sicher, dass das Ziel bei einer einzelnen Anfrage über einen normalen Browser oder das Tool curl schnell und stabil antwortet.
3. Holen Sie sich die Proxeon-Proxy-Daten aus Ihrem Konto: Host, Port, Benutzername und Passwort.
4. Erstellen Sie die Verbindungszeichenfolge im Format http://BENUTZERNAME:PASSWORT@HOST:PORT. Beispiel: http://user:pass@proxy.proxeon.net:8000.
5. Überprüfen Sie den Proxy mit einer einzelnen curl-Anfrage, indem Sie Ihre Daten anstelle des Beispiels einsetzen.

Beispiel für eine Testanfrage:

curl -x http://user:pass@proxy.proxeon.net:8000 -H "Accept: application/json" https://stend.local/api/health

⚠️ Achtung: Speichern Sie Benutzername und Passwort des Proxys niemals direkt im Code, der in ein Repository gelangt. Verwenden Sie Umgebungsvariablen. Das zeigen wir in den nächsten Schritten.

Erwartetes Ergebnis: curl über den Proxy liefert eine korrekte Antwort von Ihrem Ziel ohne Verbindungsfehler.

Mögliche Probleme: Wenn curl hängt – prüfen Sie Port und Firewall. Bei Autorisierungsfehler 407 – überprüfen Sie Benutzername und Passwort.

✅ Überprüfung: Sie sehen den Antwortinhalt vom Ziel, der genau über den Proxy erhalten wurde. Die Kette funktioniert also.

Schritt 2: Die richtige Lastmethodik verstehen

Ziel dieses Schritts: Verstehen, warum ein einmaliger Schlag nutzlos ist und wie man ein korrektes Lastprofil aufbaut.

Warum ein einmaliger Schlag irreführend ist

Wenn Sie tausend Anfragen auf einmal starten, erhalten Sie eine schöne, aber bedeutungslose Zahl. Ein solcher Schlag zeigt kein stabiles Verhalten. Das System kann den Spitzenstoß dank Puffern schlucken und dann degradieren. Oder es erstickt am Anfang wegen kalter Verbindungen.

Drei Phasen eines korrekten Tests

Ein korrekter Lasttest besteht aus drei Phasen:

1. Aufwärmen (Warm-up). In den ersten 30–60 Sekunden erhöhen wir die Last langsam. Verbindungspools, DNS-Caches und interne Strukturen werden aufgewärmt. Daten aus dem Aufwärmen nehmen wir nicht in die endgültige Statistik auf.
2. Stufenweiser Anstieg (Ramp-up Steps). Wir erhöhen die Parallelität stufenweise: zum Beispiel 10, 25, 50, 100, 200 VU, wobei wir auf jeder Stufe 1–2 Minuten verweilen. So sehen wir, auf welcher Stufe die Degradation beginnt.
3. Stabile Phase (Steady State). Wir fixieren die Last auf einem Niveau knapp unterhalb der Grenze und halten sie 5–10 Minuten. Die Phase zeigt, ob das System unter konstanter Last stabil bleibt, ob es Lecks oder aufgestaute Warteschlangen gibt.

Tipp: Ziehen Sie niemals Schlussfolgerungen aus den ersten 30 Sekunden eines Tests. Lassen Sie das System in den stabilen Zustand übergehen, dann sehen Sie die Zahlen an.

Was wir auf jeder Stufe festhalten

• Erreichten RPS.
• Latenzen p50, p95, p99.
• Fehlerquote.
• Anzahl aktiver VU oder Threads.

Den Degradationspunkt bestimmen wir so: Wir finden die Stufe, nach der der RPS nicht mehr steigt, aber p95 und Fehlerquote stark zunehmen. Die vorherige Stufe ist Ihr sicherer Arbeitspunkt.

✅ Überprüfung: Sie können in eigenen Worten erklären, wie sich Aufwärmen von der stabilen Phase unterscheidet und warum der stufenweise Anstieg nötig ist.

Schritt 3: k6 – fertiges Skript mit Proxy und Laststufen

Ziel dieses Schritts: Ein funktionierendes k6-Skript erstellen und ausführen, das Aufwärmen, Stufen und stabile Phase über den Proxy durchläuft.

Wie k6 mit Proxys arbeitet

k6 liest die Proxy-Adresse aus den Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY. Das ist praktisch: Sie müssen die Daten nicht im Skript hartkodieren, sondern nur beim Start übergeben.

Fertiges Skript load-test.js

Erstellen Sie eine Datei load-test.js und fügen Sie den folgenden Code ein. Ersetzen Sie die Zieladresse durch Ihre eigene.

import http from 'k6/http'; import { check, sleep } from 'k6'; import { Trend, Rate, Counter } from 'k6/metrics'; const latency = new Trend('req_latency', true); const errors = new Rate('req_errors'); const ok = new Counter('req_ok'); export const options = { discardResponseBodies: true, thresholds: { req_errors: ['rate<0.02'], http_req_duration: ['p(95)<1500', 'p(99)<3000'], }, scenarios: { ramp: { executor: 'ramping-vus', startVUs: 0, stages: [ { duration: '1m', target: 10 }, { duration: '2m', target: 25 }, { duration: '2m', target: 50 }, { duration: '2m', target: 100 }, { duration: '2m', target: 200 }, { duration: '5m', target: 200 }, { duration: '1m', target: 0 }, ], gracefulRampDown: '30s', }, }, }; const TARGET = __ENV.TARGET_URL || 'https://stend.local/api/health'; export default function () { const res = http.get(TARGET, { timeout: '10s', tags: { name: 'target' } }); latency.add(res.timings.duration); const good = check(res, { 'status is 200': (r) => r.status === 200 }); errors.add(!good); if (good) ok.add(1); sleep(0.5); }

So starten Sie das Skript über den Proxy

1. Öffnen Sie ein Terminal im Ordner mit dem Skript.
2. Setzen Sie Umgebungsvariablen mit der Proxy-Adresse und dem Ziel. Unter Linux und macOS führen Sie den Export der Variablen aus.
3. Starten Sie k6 mit dem Befehl zum Ausführen des Skripts.

Beispiel für den Start unter Linux und macOS:

export HTTP_PROXY=http://user:pass@proxy.proxeon.net:8000 export HTTPS_PROXY=http://user:pass@proxy.proxeon.net:8000 export TARGET_URL=https://stend.local/api/health k6 run load-test.js

Unter Windows in PowerShell werden Variablen mit $env gesetzt:

$env:HTTP_PROXY="http://user:pass@proxy.proxeon.net:8000"; $env:HTTPS_PROXY="http://user:pass@proxy.proxeon.net:8000"; $env:TARGET_URL="https://stend.local/api/health"; k6 run load-test.js

Tipp: Der Parameter discardResponseBodies deaktiviert das Speichern der Antwortinhalte im Speicher. Das reduziert die Last auf dem Generator selbst und hilft, seine Überlastung nicht mit der Proxy-Grenze zu verwechseln.

k6-Bericht lesen

Nach dem Test gibt k6 eine Zusammenfassung aus. Achten Sie auf die wichtigsten Zeilen:

• http_reqs – Gesamtzahl der Anfragen und durchschnittlicher RPS in Klammern. Das ist Ihr Durchsatz.
• http_req_duration – Latenzen mit avg, min, med, max und Perzentilen p(90), p(95).
• req_errors und http_req_failed – Fehlerquote.
• vus – Anzahl der virtuellen Benutzer im Moment.

Die Zeile thresholds zeigt, ob Ihre Schwellenwerte eingehalten wurden. Steht ein Kreuz neben der Zeile, wurde der Schwellenwert verletzt – die Grenze ist bei dieser Konfiguration erreicht oder überschritten.

⚠️ Achtung: Passen Sie die Zielwerte in stages an Ihr System an. Der Wert 200 VU ist nur ein Beispiel. Wenn Ihr Ziel oder das Tariflimit des Proxys kleiner ist, beginnen Sie mit bescheideneren Stufen, z. B. bis 50.

Erwartetes Ergebnis: Der Test ist abgeschlossen, Sie sehen eine Zusammenfassung mit RPS, Perzentilen und Fehlerquote.

Mögliche Probleme: Wenn alle Anfragen fehlschlagen, prüfen Sie die Proxy-Variablen. Wenn der Generator 100 Prozent CPU verbraucht, reduzieren Sie die VU-Anzahl oder nutzen Sie einen stärkeren Rechner.

✅ Überprüfung: In der k6-Zusammenfassung wird ein von null verschiedener http_reqs angezeigt und die Fehlerquote liegt unter Ihrem Schwellenwert, zumindest auf den ersten Stufen.

Schritt 4: JMeter – dasselbe Szenario mit Proxy-Konfiguration im Testplan

Ziel dieses Schritts: Einen äquivalenten Plan in JMeter mit Proxy, Stufen und Metriksammlung erstellen.

Thread Group erstellen

1. Im geöffneten JMeter klicken Sie mit der rechten Maustaste auf das Element Test Plan.
2. Wählen Sie Add – Threads (Users) – Thread Group.
3. Im Feld Number of Threads setzen Sie die maximale Thread-Anzahl, z. B. 200.
4. Im Feld Ramp-up period geben Sie die Zeit in Sekunden an, in der die volle Last erreicht wird, z. B. 540, um den stufenweisen Anstieg aus k6 zu wiederholen.
5. Im Feld Loop Count setzen Sie das Häkchen Infinite, die Dauer definieren wir über den Timer und den Scheduler.

Proxy in HTTP Request Defaults konfigurieren

Um den Proxy nicht in jeder Anfrage einzeln zu setzen, definieren wir ihn einmal.

1. Klicken Sie mit der rechten Maustaste auf die Thread Group und wählen Sie Add – Config Element – HTTP Request Defaults.
2. Im geöffneten Element finden Sie den Bereich mit den Proxy-Einstellungen.
3. Im Feld Server Name or IP (im Block Proxy) geben Sie den Proxy-Host ein, z. B. proxy.proxeon.net.
4. Im Feld Port Number (Proxy) geben Sie den Port ein, z. B. 8000.
5. In die Felder Username und Password (Proxy) tragen Sie Ihren Benutzernamen und Ihr Passwort ein.

HTTP-Anfrage hinzufügen

1. Klicken Sie mit der rechten Maustaste auf die Thread Group und wählen Sie Add – Sampler – HTTP Request.
2. Im Feld Protocol geben Sie https ein.
3. Im Feld Server Name or IP geben Sie die Domain des Ziels ein, z. B. stend.local.
4. Im Feld Path geben Sie den Pfad ein, z. B. /api/health.
5. Im Feld Method lassen Sie GET.

Verzögerung zwischen Anfragen hinzufügen

1. Klicken Sie mit der rechten Maustaste auf die HTTP Request und wählen Sie Add – Timer – Constant Timer.
2. Im Feld Thread Delay geben Sie 500 Millisekunden ein, um den sleep aus k6 nachzubilden.

Metriksammlung konfigurieren

1. Klicken Sie mit der rechten Maustaste auf die Thread Group und fügen Sie Add – Listener – Summary Report hinzu.
2. Fügen Sie auch Add – Listener – Aggregate Report hinzu – er zeigt Perzentile.
3. Für lange Tests verwenden Sie keine grafischen Listener, sie verbrauchen Speicher. Speichern Sie die Ergebnisse stattdessen in einer Datei.

Tipp: Für schwere Tests starten Sie JMeter im nicht-grafischen Modus über die Kommandozeile. So verwendet der Generator Ressourcen für die Last statt für die Darstellung.

Beispiel für den Start im nicht-grafischen Modus:

jmeter -n -t plan.jmx -l results.jtl -e -o report

Hier startet -n ohne Grafik, -t zeigt die Plandatei an, -l die Datei mit Rohdaten und -e -o erstellt einen HTML-Bericht im Ordner report.

JMeter-Bericht lesen

Öffnen Sie index.html aus dem Ordner report. Die wichtigsten Kennzahlen:

• Throughput – Durchsatz in Anfragen pro Sekunde.
• Response Times Percentiles – Diagramm der Latenz-Perzentile.
• Error percentage – Fehlerquote.
• Active Threads Over Time – wie die Parallelität gestiegen ist.

⚠️ Achtung: Bei der Proxy-Authentifizierung kann JMeter zusätzliche Einstellungen für die Basic-Autorisierung erfordern. Wenn Sie massiv Fehler 407 sehen, fügen Sie ein HTTP Authorization Manager-Element mit den Proxy-Daten hinzu.

Erwartetes Ergebnis: Der HTML-Bericht von JMeter öffnet sich und zeigt Throughput, Perzentile und Fehlerquote.

✅ Überprüfung: Die Throughput- und Perzentilwerte in JMeter sind vergleichbar mit den k6-Ergebnissen bei denselben Stufen. Kleine Abweichungen sind normal.

Schritt 5: Proxy-Grenze von Client-Grenze und Serverlimit unterscheiden – drei Prüfungen

Ziel dieses Schritts: Genau bestimmen, welcher der drei Knoten zum Engpass geworden ist.

Wenn Sie eine Degradation sehen, ist es wichtig, die Quelle zu kennen. Führen Sie drei Kontrollprüfungen durch.

Prüfung 1: Liegt es an Ihrem Client?

1. Öffnen Sie während des Tests den Systemmonitor auf dem Generatorrechner.
2. Beobachten Sie die CPU-Auslastung und den Arbeitsspeicher des Prozesses k6 oder JMeter.
3. Prüfen Sie das Limit für geöffnete Dateideskriptoren unter Linux mit dem Befehl ulimit -n.

Wenn die CPU des Generators nahe 100 Prozent liegt oder das Deskriptorenlimit erreicht ist, liegt es am Client, nicht am Proxy. Erhöhen Sie das Deskriptorenlimit, reduzieren Sie die VU-Anzahl oder verwenden Sie einen stärkeren Rechner.

Tipp: Ein Zeichen für Client-Überlastung sind steigende Latenzen bei gleichzeitig steigender CPU-Auslastung des Generators und gleichbleibendem RPS. Der Proxy ist hier nicht beteiligt.

Prüfung 2: Liegt es am Zielserver?

1. Starten Sie einen kurzen Test direkt ohne Proxy, indem Sie die Variablen HTTP_PROXY und HTTPS_PROXY entfernen.
2. Vergleichen Sie RPS und Perzentile mit den Ergebnissen über den Proxy.

Wenn sowohl direkt als auch über den Proxy die RPS-Grenze fast identisch ist – liegt der Engpass am Zielserver. Der Proxy fügt nur eine kleine feste Latenz hinzu.

⚠️ Achtung: Den Test direkt führen Sie nur gegen Ihr eigenes Testsystem durch. Belasten Sie fremde Ressourcen ohne Erlaubnis auch zu Diagnosezwecken nicht.

Prüfung 3: Proxy isolieren

1. Starten Sie auf Ihrem Testsystem einen leichten Stub, der sofort 200 OK mit leerem Inhalt zurückgibt.
2. Führen Sie den Test über den Proxy gegen diesen Stub aus.

Der Stub antwortet fast sofort, daher bestimmen nun der Proxy und das Netz die Latenzen und die RPS-Grenze. Wenn der RPS genau beim Stub gegen eine Decke stößt – haben Sie die Proxy-Grenze gefunden.

Fassen wir die Logik in einer einfachen Entscheidungstabelle zusammen:

• CPU des Generators hoch, RPS steigt nicht – Client-Grenze.
• Direkt und über Proxy gleich – Zielserver-Grenze.
• Beim schnellen Stub über Proxy ist der RPS am Limit – Proxy-Grenze.

Erwartetes Ergebnis: Sie benennen den konkreten Knoten, der Ihre Kette einschränkt.

✅ Überprüfung: Sie haben alle drei Prüfungen durchgeführt und können begründen, wo sich der Engpass befindet.

Schritt 6: Mit dem Ergebnis arbeiten – Threads, Pool und Auslastungszeit

Ziel dieses Schritts: Die Testzahlen in praktische Einstellungen für Ihre Arbeitsaufgabe umwandeln.

Sichere Thread-Anzahl wählen

Nehmen Sie die Stufe vor dem Degradationspunkt. Angenommen, bei 100 VU erhalten Sie stabile 180 RPS, p95 um 900 ms und Fehler unter 1 Prozent, während bei 200 VU der RPS nicht steigt, aber p95 auf 4 Sekunden springt. Dann ist der Arbeitspunkt etwa 100 VU, für Sicherheit nehmen Sie 80–90.

Pool-Größe berechnen

Wenn ein Proxy-Knoten stabil N parallele Verbindungen hält und Sie M gleichzeitige benötigen, ist die minimale Pool-Größe M geteilt durch N, aufgerundet, plus Sicherheitsmarge. Eine Marge von 20–30 Prozent deckt Momente ab, in denen ein Teil der Verbindungen durch langsame Antworten belegt ist.

Tipp: Planen Sie immer eine Pool-Reserve ein. Echte Antworten sind langsamer als der Stub, daher werden Verbindungen länger gehalten und die tatsächliche Parallelität ist höher als berechnet.

Auslastungszeit schätzen

Die Formel ist einfach: Zeit in Sekunden ist die Gesamtzahl der Anfragen geteilt durch den stabilen RPS. Wenn Sie 1.000.000 Anfragen bei stabilen 180 RPS sammeln müssen, sind das etwa 5556 Sekunden, also rund 1 Stunde 33 Minuten ohne Pausen und Wiederholungen.

1. Nehmen Sie den stabilen RPS von der Arbeitsstufe.
2. Teilen Sie das Gesamtvolumen der Aufgabe durch diesen RPS.
3. Fügen Sie 15–20 Prozent für Wiederholungen fehlgeschlagener Anfragen und Pausen hinzu.

Beispielrechnung als Pseudocode zur Veranschaulichung:

total = 1000000; rps = 180; base_sec = total / rps; final_sec = base_sec * 1.2; 






Über den Autor










Roman Melnikov
Technical Writer and System Administrator







Berufserfahrung:
Technical writer and DevOps engineer with 9 years of experience. Created over 50 detailed guides on system configuration and administration. His instructions helped thousands of professionals successfully solve technical tasks. Popular author on Habr and YouTube.







Ausbildung:

Bauman Moscow State Technical University. Information Systems and Technologies








Expertise:

Technical Documentation
DevOps
System Administration
Linux
Docker and Kubernetes
CI/CD
Infrastructure Automation
Cloud Technologies
System Monitoring
Bash and Python Scripting












Diesen Artikel teilen: