Fehlerbehebung bei Lasttests

Suchen Sie die Meldung oder das Symptom, das Sie sehen, und lesen Sie, warum es auftritt und was zu tun ist. Jeder Eintrag verweist auf die Seite mit allen Details. Meldungen sind so zitiert, wie die App sie anzeigt.

Der Test startet nicht

"Failed to start test"

Was Sie sehen: einen Dialog mit dem Titel Failed to start test und dem Text "Please try again. If you still encounter an error please contact us."

Warum: LoadFocus konnte den Lauf nicht starten, und der Grund war keines der unten beschriebenen Tariflimits.

Was tun: Starten Sie den Test erneut. Ein Lauf, den LoadFocus nicht starten konnte, zählt nicht gegen die Läufe Ihres Tarifs (siehe den letzten Abschnitt dieser Seite). Schlägt er weiterhin fehl, wenden Sie sich mit dem Testnamen an den Support.

"Testlauf-Limit erreicht"

Was Sie sehen: Der Limit-Dialog zeigt Testlauf-Limit erreicht mit einer Zeile wie "Ihr Tarif umfasst 30 Testläufe innerhalb von 24 Stunden. Ihr Team hat 30 genutzt." und dem Datum, ab dem der nächste Testlauf möglich ist. Über die API enthält die Ablehnung einen Grund wie number-of-daily-tests-exceeded, number-of-weekly-tests-exceeded, number-of-monthly-tests-exceeded oder number-of-yearly-tests-exceeded, mit den Zählern current und maximum.

Warum: Ihr Team hat alle Läufe genutzt, die sein Tarif in diesem Zeitraum erlaubt. Das Wochenlimit gilt nur für Läufe, die über die API gestartet werden, und für geplante Läufe, und nur bei Load Free, in der Testphase und bei Load Starter.

Was tun: Warten Sie bis zum angezeigten Datum oder wechseln Sie in einen Tarif mit mehr Läufen. Geplante Läufe, die an ein Limit stoßen, werden übersprungen, und das Zeitplan-Panel nennt den Grund. Siehe Tarife und Limits und Geplante Lasttests.

"Ihr Tarif hat die Anzahl der Tests erreicht, die gleichzeitig laufen können."

Warum: Ein anderer Test Ihres Teams läuft noch, und Ihr Tarif erlaubt nur so viele Tests gleichzeitig.

Was tun: Warten Sie, bis der laufende Test beendet ist, oder stoppen Sie ihn. Siehe Tarife und Limits.

Ablehnungen in der Testphase: "Sie haben Ihre Testläufe der Testphase aufgebraucht", "Dieser Test braucht mehr virtuelle Nutzer", "Für diese Website brauchen Sie einen bezahlten Tarif"

Warum: In der 7-tägigen Testphase eines bezahlten Tarifs laufen Tests mit reduzierten Limits: 50 virtuelle Benutzer, Tests bis 5 Minuten und 3 Läufe innerhalb von 24 Stunden, über Cloud-, JMeter- und k6-Tests zusammen. Ein Cloud-Test aus einer Testphase kann außerdem keine Website testen, die bereits aus einer anderen Testphase oder einem Free-Konto lastgetestet wurde.

Was tun: Der Dialog bietet an, Ihren Tarif sofort zu starten, was die Limits der Testphase direkt aufhebt, oder eine Karte für 3 weitere Läufe heute hinzuzufügen. Siehe Limits während der 7-tägigen Testphase.

"Kostenlose Tests für diese Website aufgebraucht"

Warum: Alle Free-Konten zusammen erhalten 3 Tests pro Tag und 10 pro Jahr für dieselbe Website, und dieses gemeinsame Kontingent ist aufgebraucht. Es greift erst, wenn ein anderes Konto diese Website im selben Zeitraum getestet hat.

Was tun: Der Dialog sagt, wann Sie die Website wieder kostenlos testen können. Ihre anderen Websites sind nicht betroffen, und bezahlte Tarife haben kein gemeinsames Kontingent. Siehe Limits im Free-Plan.

"The test cannot run because the URL fields contain private IP addresses."

Warum: Eine Anfrage-URL zeigt auf localhost, auf eine private Adresse wie 192.168.x.x oder 10.x.x.x oder auf einen Hostnamen, der zu einer solchen Adresse aufgelöst wird. Lastgeneratoren laufen in der Cloud und erreichen Ihr internes Netzwerk nicht.

Was tun: Testen Sie eine öffentliche URL oder machen Sie den lokalen Server über einen Tunnel erreichbar. Siehe Was ist eine gültige URL für einen Lasttest und Lasttests für lokal gehostete Websites oder APIs.

Der Test startet, schlägt aber fehl

Ein k6-Test endet als FAILED ohne Ergebnisse

Was Sie sehen: Die k6-Testliste zeigt FAILED, und die Ergebnisseite öffnet einen Dialog Test run failed.

Warum: Das Skript ist fehlgeschlagen, bevor es Last erzeugt hat: ein Syntaxfehler, ein Import, der nicht geladen werden kann (etwa eine k6/x/...-Erweiterung), oder ein setup(), das eine Ausnahme wirft oder in eine Zeitüberschreitung läuft. Ein teardown(), das nach dem Test eine Ausnahme wirft, lässt den Lauf nicht fehlschlagen.

Was tun: Führen Sie das Skript lokal mit k6 run aus, um den Fehler zu finden, beheben Sie ihn und laden Sie das Skript erneut hoch. Die k6-Logdatei finden Sie im Tab Protokolle. Siehe Analyse der k6 Lasttest-Ergebnisse.

Ein JMeter-Test schlägt fehl oder sendet weniger Anfragen als erwartet

Was Sie sehen: einen Dialog Test run failed mit "Please try again. There were errors reported during the test run." und einem Auszug aus dem JMeter-Log, oder einen Lauf, der mit weit weniger Samples endet als geplant.

Warum: JMeter hat beim Ausführen Ihres Skripts Fehler gemeldet, zum Beispiel ein fehlendes Plugin, eine falsch konfigurierte Thread-Gruppe oder eine CSV-Datei, die das Skript liest, die aber nicht hochgeladen wurde.

Was tun: Öffnen Sie den Tab Protokolle, lesen Sie die JMeter-Logdatei und suchen Sie darin nach ERROR und WARN. Siehe JMeter-Logdateianalyse und Logs & JTL-Dateianalyse.

Die Ergebnisse sehen falsch aus

Der Startbildschirm meldet, dass eine Testanfrage abgewiesen wurde

Was Sie sehen: Während ein Cloud-Test startet, eine Warnung wie "Cloudflare hat eine Testanfrage an example.com von AWS us-east-1 abgewiesen. Ihr Lasttest wird möglicherweise genauso blockiert."

Warum: Beim Start eines Cloud-Laufs sendet LoadFocus eine Anfrage an die Startseite der Website aus der Region des Laufs. Ein CDN oder die Edge des Hosting-Anbieters vor der Website hat sie abgelehnt. Es ist nur eine Anfrage ohne die Zugangsdaten Ihres Tests, also ein Hinweis und kein Urteil, und der Lauf geht weiter.

Was tun: Beobachten Sie die Fehlerrate des Laufs. Zeigen die Ergebnisse danach den unten beschriebenen Filterhinweis, geben Sie den Testverkehr in den Firewall- oder Bot-Schutz-Einstellungen dieser Plattform frei.

"... filtert wahrscheinlich den Testverkehr."

Was Sie sehen: In der Ergebnisübersicht eines beendeten Cloud-Tests einen Hinweis wie "Vercel filtert wahrscheinlich den Testverkehr." oder "Diese Website scheint den Testverkehr zu drosseln oder zu blockieren."

Warum: Mindestens 20 % der Anfragen endeten mit 403, 429, 430 (503 bei Cloudflare) oder einer abgebrochenen oder fehlgeschlagenen Verbindung, also mit dem, was Bot-Schutz, DDoS-Schutz und Ratenlimits erzeugen. Die Zahlen beschreiben diesen Schutz, nicht Ihre Website.

Was tun: Geben Sie den Testverkehr über die freizugebenden IP-Bereiche frei, oder testen Sie eine Staging-Umgebung mit gelockertem Schutz. Siehe Fehler nach Typ und Fehlerrate.

"Lastgenerator nahe der Kapazitätsgrenze - Antwortzeiten als Untergrenze betrachten"

Warum: Mindestens ein Lastgenerator hat während des Laufs 80 % CPU oder mehr erreicht. Die Antwortzeiten enthalten deshalb Zeit, in der der Generator auf seine eigene CPU gewartet hat.

Was tun: Verteilen Sie die Benutzer auf mehr Lastgeneratoren oder Standorte, entfernen Sie aufwendige Arbeit pro Anfrage aus dem Skript und führen Sie den Test erneut aus. Siehe Auslastung der Lastgeneratoren.

Verbindungsfehler: ConnectException, HttpHostConnectException, Zeitüberschreitungen

Was Sie sehen: Zeilen im Tab Fehler wie HttpHostConnectException oder SocketTimeoutException, oder "Der Hostname konnte nicht aufgelöst werden (DNS)." in den Erklärungen der Antwortcodes.

Warum: Die Lastgeneratoren konnten keine Verbindung öffnen oder haben keine Antwort erhalten: Der Host ist nicht erreichbar, der Name lässt sich aus dem Internet nicht auflösen, oder eine Firewall verwirft den Verkehr der Generatoren.

Was tun: Prüfen Sie, ob die URL von außerhalb Ihres Netzwerks funktioniert, und tragen Sie die LoadFocus-IP-Bereiche in Ihre Firewall oder WAF ein. Beginnen die Fehler erst ab einer bestimmten Benutzerzahl, handelt es sich um eine Kapazitätsgrenze: Vergleichen Sie sie mit der Linie der virtuellen Benutzer. Siehe Fehler nach Typ und Fehlerrate.

HTTPS-Fehler: SSLException, SSLHandshakeException

Was Sie sehen: SSLException oder SSLHandshakeException im Tab Fehler, oder "Die sichere Verbindung (TLS) konnte nicht hergestellt werden."

Warum: Der TLS-Handshake ist fehlgeschlagen. Häufige Ursachen sind ein abgelaufenes, selbst signiertes oder privat ausgestelltes Zertifikat, ein Protokollkonflikt oder ein Server, der unter Last Handshakes abbricht.

Was tun: Prüfen Sie die Zertifikatskette des Hosts, zum Beispiel mit dem kostenlosen SSL Checker. Nehmen die Fehler mit der Benutzerzahl zu, kommt der Server mit den Handshakes nicht nach. Siehe Unterschiede zwischen HTTP und HTTPS.

Ein alter Lauf ist als "Abgelaufen" markiert und seine Diagramme sind leer

Warum: Rohdaten, die älter als 1 Jahr sind, werden gelöscht. Der Lauf bleibt in Ihrer Liste, aber seine Diagramme haben keine Daten mehr. Läufe, die als Baseline gesetzt sind, behalten ihre Rohdaten.

Was tun: Hier ist nichts zu beheben. Siehe Wie lange LoadFocus Ihre Daten aufbewahrt.

Läufe, die nicht zählen

• Ein Lauf, den LoadFocus nicht starten konnte, zählt nicht gegen die Laufgrenzen Ihres Tarifs.
• Ein Cloud-Testlauf, der endete, ohne eine einzige Anfrage zu senden, zählt ebenfalls nicht, bis zu zwei solcher Läufe pro Tag.
• Ein Lauf, den Sie selbst stoppen, zählt immer, auch wenn er noch keine Last erzeugt hat.

Wie übersprungene geplante Läufe gemeldet werden, lesen Sie unter Geplante Lasttests.