Lasttests für lokal gehostete Websites oder APIs
Warum Sie eine öffentliche URL benötigen
Unsere Lastgeneratoren sind in der Cloud gehostet, daher muss Ihr Dienst, Ihre Website, API oder Ihr Webdienst öffentlich erreichbar sein, damit unsere Lasttest-Agenten Ihren Endpunkt erreichen können.
Wenn Sie Ihren Dienst, Ihre Website, API oder Ihren Webdienst lokal hosten, gibt es einige Tools, mit denen Sie eine lokal gehostete Website dem Internet zugänglich machen können.
Lastgeneratoren laufen in Cloud-Rechenzentren, nicht auf Ihrem Rechner, daher können sie http://localhost, einen privaten IP-Bereich wie 192.168.x.x oder 10.x.x.x, oder einen Port, der nur auf Ihrem Laptop gebunden ist, niemals auflösen. Die vollständige Liste dessen, was als erreichbares Ziel zählt, finden Sie unter https://loadfocus.com/docs/de-de/knowledge-base/using-valid-url-endpoints.
Tools, die einen lokalen Server für das Internet freigeben
Hier sind Dienste, mit denen Sie bestimmte Ports auf Ihrem lokalen Rechner freigeben können, sodass die Außenwelt eine Verbindung herstellen kann:
Die oben genannten Dienste ermöglichen es Ihnen, einen Webdienst auf Ihrem lokalen Entwicklungsrechner einfach freizugeben, ohne DNS- und Firewall-Einstellungen ändern zu müssen.
Wie Tunnel-Tools funktionieren
Beide Tools folgen demselben Grundmuster: Ein kleiner Client auf Ihrem Rechner öffnet eine ausgehende Verbindung zum Relay-Server des Tunnel-Anbieters (ausgehende Verbindungen werden von Firewalls oder NAT selten blockiert). Der Anbieter weist eine öffentliche URL zu und leitet eingehende Anfragen auf dieser URL durch den Tunnel zurück an den Port, den Sie lokal freigegeben haben. Es sind keine DNS-Änderungen, keine Port-Weiterleitung und keine Firewall-Regeln nötig, weshalb dies der schnellste Weg ist, eine lokale App für einen schnellen Test erreichbar zu machen.
Worauf Sie vor einem Lasttest über einen Tunnel achten sollten
- Limits der kostenlosen Stufe: Die meisten kostenlosen Tunnel-Pläne begrenzen Bandbreite oder die Anzahl gleichzeitiger Verbindungen. Bei echter Last, Hunderten oder Tausenden virtueller Benutzer, kann die eigene Obergrenze des Tunnels erreicht werden, bevor die Ihrer Anwendung erreicht wird, und die Zahlen, die Sie zurückbekommen, beschreiben dann den Tunnel, nicht Ihre App.
- Zusätzliche Latenz: Jede Anfrage macht jetzt einen zusätzlichen Hop über den Relay-Server des Tunnel-Anbieters. Antwortzeiten werden höher sein als das, was derselbe Code zeigen würde, sobald er hinter Ihrer normalen Infrastruktur bereitgestellt ist. Behandeln Sie absolute Zahlen daher mit Vorsicht.
- Stabilität während des Tests: Wenn der Tunnel-Prozess abstürzt oder der Rechner, auf dem er läuft, in den Ruhezustand geht oder die Netzwerkverbindung verliert, schlagen alle laufenden Anfragen gleichzeitig fehl. Für alles, was über einen kurzen Smoke-Test hinausgeht, betreiben Sie den Tunnel auf einem dauerhaft laufenden Rechner statt auf einem Laptop.
- Exposition: Ein Tunnel macht Ihre lokale Umgebung für jeden erreichbar, der die generierte URL kennt oder errät, solange der Tunnel geöffnet bleibt. Halten Sie das Zeitfenster der Exposition kurz, nutzen Sie die Authentifizierungsoptionen des Anbieters, falls verfügbar, und vermeiden Sie es, eine Umgebung zu tunneln, die echte Produktionsdaten enthält.
Wann ein Tunnel das richtige Werkzeug ist
Ein Tunnel eignet sich gut für einen schnellen Sanity-Check: um zu bestätigen, dass ein Endpunkt eine moderate Anzahl gleichzeitiger Anfragen verkraftet, bevor er ausgeliefert wird, oder um ein in einem Cloud-Test gefundenes Problem gegen einen lokalen Build zu reproduzieren. Für ernsthafte Kapazitätsplanung oder Benchmark-Zahlen stellen Sie stattdessen in einer Staging-Umgebung bereit, die die Produktionsinfrastruktur so genau wie möglich abbildet. Der Tunnel-Hop fügt Rauschen hinzu, das absolute Antwortzeiten unzuverlässig macht, auch wenn relative Vergleiche, also dasselbe getunnelte Setup vor und nach einer Codeänderung zu testen, weiterhin etwas Nützliches aussagen können.