Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Designüberlegungen
In diesem Abschnitt werden wichtige Designentscheidungen und Konfigurationsoptionen für die Distributed Load Testing on AWS-Lösung beschrieben, einschließlich unterstützter Anwendungen, Testtypen, Planungsoptionen und Überlegungen zur Bereitstellung.
Unterstützte Anwendungen
Diese Lösung unterstützt das Testen von cloudbasierten Anwendungen und lokalen Anwendungen, sofern Sie über eine Netzwerkverbindung zwischen Ihrem AWS-Konto und Ihrer Anwendung verfügen. Die Lösung unterstützt APIs die Verwendung von HTTP- oder HTTPS-Protokollen.
Testtypen
Distributed Load Testing auf AWS unterstützt mehrere Testtypen: einfache HTTP-Endpunkttests JMeter, K6 und Locust.
Einfache HTTP-Endpunkttests
Die Webkonsole bietet eine Schnittstelle zur Konfiguration von HTTP-Endpunkten, mit der Sie jeden HTTP- oder HTTPS-Endpunkt testen können, ohne benutzerdefinierte Skripts schreiben zu müssen. Sie definieren die Endpunkt-URL, wählen die HTTP-Methode (GET, POST, PUT, DELETE usw.) aus einem Dropdownmenü aus und fügen optional benutzerdefinierte Anforderungsheader und Body-Payloads hinzu. Diese Konfiguration ermöglicht es Ihnen, APIs mit benutzerdefinierten Autorisierungstoken, Inhaltstypen oder anderen HTTP-Headern und Anforderungstexten zu testen, die für Ihre Anwendung erforderlich sind.
JMeter Tests
Wenn Sie ein Testszenario mit der Webkonsole erstellen, können Sie ein JMeter Testskript hochladen. Die Lösung lädt das Skript in den S3-Bucket des Szenarios hoch. Wenn Amazon ECS-Aufgaben ausgeführt werden, laden sie das JMeter Skript von S3 herunter und führen den Test aus.
Wichtig
Ihr JMeter Skript kann zwar Parallelität (virtuelle Benutzer), Transaktionsraten (TPS), Anlaufzeiten und andere Ladeparameter definieren, aber die Lösung überschreibt diese Konfigurationen mit den Werten, die Sie während der Testerstellung auf dem Traffic Shape-Bildschirm angeben. Die Traffic Shape-Konfiguration steuert die Anzahl der Aufgaben, die Parallelität (virtuelle Benutzer pro Aufgabe), die Dauer des Hochlaufs und die Haltedauer für die Testausführung.
Wenn Sie über JMeter Eingabedateien verfügen, können Sie die Eingabedateien zusammen mit dem Skript komprimieren. JMeter Sie können die ZIP-Datei auswählen, wenn Sie ein Testszenario erstellen.
Wenn Sie Plugins einbeziehen möchten, werden alle .jar-Dateien, die in einem /plugins-Unterverzeichnis der mitgelieferten ZIP-Datei enthalten sind, in das JMeter Erweiterungsverzeichnis kopiert und stehen dort für Auslastungstests zur Verfügung.
Anmerkung
Wenn Sie Ihrer JMeter Skriptdatei JMeter Eingabedateien hinzufügen, müssen Sie den relativen Pfad der Eingabedateien in Ihrer Skriptdatei angeben. JMeter Außerdem müssen sich die Eingabedateien im relativen Pfad befinden. Wenn sich Ihre JMeter Eingabedateien und die Skriptdatei beispielsweise stattdessen im Verzeichnis/home/user directory and you refer to the input files in the JMeter script file, the path of input files must be ./INPUT_FILES. If you use /home/user/INPUT_FILES befinden, schlägt der Test fehl, da die Eingabedateien nicht gefunden werden können.
Wenn Sie JMeter Plugins einbeziehen, müssen die .jar-Dateien in einem Unterverzeichnis namens /plugins im Stammverzeichnis der ZIP-Datei gebündelt werden. Relativ zum Stammverzeichnis der ZIP-Datei muss der Pfad zu den JAR-Dateien sein. /Plugins/Bundled_Plugin.jar.
Weitere Informationen zur Verwendung von Skripten finden Sie im Benutzerhandbuch. JMeter JMeter
K6-Tests
Die Lösung unterstützt Tests auf Basis des K6-Frameworks. K6 ist unter der AGPL-3.0-Lizenz veröffentlicht.
Wichtig
Ihr K6-Skript kann zwar Parallelität (virtuelle Benutzer), Stufen, Schwellenwerte und andere Ladeparameter definieren, aber die Lösung überschreibt diese Konfigurationen mit den Werten, die Sie bei der Testerstellung im Traffic Shape-Bildschirm angeben. Die Traffic Shape-Konfiguration steuert die Anzahl der Aufgaben, die Parallelität (virtuelle Benutzer pro Aufgabe), die Dauer des Hochlaufs und die Haltedauer für die Testausführung.
Locust testet
Die Lösung unterstützt Tests auf Basis des Locust Frameworks. Sie können die Locust-Testdatei zusammen mit allen erforderlichen Eingabedateien in eine Archivdatei hochladen.
Wichtig
Ihr Locust-Skript kann zwar Parallelität (Benutzeranzahl), Spawn-Rate und andere Ladeparameter definieren, aber die Lösung überschreibt diese Konfigurationen mit den Werten, die Sie während der Testerstellung im Traffic Shape-Bildschirm angeben. Die Traffic Shape-Konfiguration steuert die Anzahl der Aufgaben, die Parallelität (virtuelle Benutzer pro Aufgabe), die Dauer des Hochlaufs und die Haltedauer für die Testausführung.
Planung von Tests
Die Lösung bietet drei Optionen zum Ausführungszeitpunkt für die Ausführung von Lasttests:
-
Jetzt ausführen — Führt den Belastungstest unmittelbar nach der Erstellung aus
-
Einmal ausführen — Führen Sie den Test an einem bestimmten Datum und zu einer bestimmten Uhrzeit in der future aus
-
Nach einem Zeitplan ausführen — Erstellen Sie wiederkehrende Tests mithilfe von Cron-Ausdrücken, um den Zeitplan zu definieren
Wenn Sie Einmal ausführen auswählen, geben Sie die Laufzeit im 24-Stunden-Format und das Ausführungsdatum an, an dem der Belastungstest ausgeführt werden soll.
Wenn Sie Nach Zeitplan ausführen auswählen, können Sie entweder manuell einen Cron-Ausdruck eingeben oder aus gängigen Cron-Mustern wählen (z. B. stündlich, täglich zu einer bestimmten Zeit, wochentags oder monatlich). Der Cron-Ausdruck verwendet ein detailliertes Zeitplanformat mit Feldern für Minuten, Stunden, Monatstag, Monat, Wochentag und Jahr. Sie müssen auch ein Ablaufdatum angeben, das festlegt, wann der geplante Test nicht mehr ausgeführt werden soll. Weitere Informationen zur Funktionsweise der Planung finden Sie im Abschnitt zum Ablauf der Testplanung in diesem Handbuch.
Anmerkung
-
Testdauer: Berücksichtigen Sie bei der Planung die Gesamtdauer der Tests. Ein Test mit einer Anlaufzeit von 10 Minuten und einer Haltezeit von 40 Minuten dauert beispielsweise etwa 80 Minuten.
-
Mindestintervall: Stellen Sie sicher, dass das Intervall zwischen den geplanten Tests länger ist als die geschätzte Testdauer. Wenn der Test beispielsweise etwa 80 Minuten dauert, sollten Sie ihn so planen, dass er nicht häufiger als alle 3 Stunden ausgeführt wird.
-
Stündliche Begrenzung: Das System erlaubt es nicht, Tests mit einem Unterschied von nur einer Stunde zu planen, selbst wenn die geschätzte Testdauer weniger als eine Stunde beträgt.
Gleichzeitige Tests
Diese Lösung erstellt für jeden Test ein CloudWatch Amazon-Dashboard, das die kombinierte Ausgabe aller im Amazon ECS-Cluster ausgeführten Aufgaben in Echtzeit anzeigt. Das CloudWatch Dashboard zeigt die durchschnittliche Antwortzeit, die Anzahl der gleichzeitigen Benutzer, die Anzahl der erfolgreichen Anfragen und die Anzahl der fehlgeschlagenen Anfragen. Die Lösung aggregiert jede Metrik sekundengenau und aktualisiert das Dashboard jede Minute.
Benutzerverwaltung
Bei der Erstkonfiguration geben Sie einen Benutzernamen und eine E-Mail-Adresse an, die Amazon Cognito verwendet, um Ihnen Zugriff auf die Webkonsole der Lösung zu gewähren. Die Konsole bietet keine Benutzerverwaltung. Um weitere Benutzer hinzuzufügen, müssen Sie die Amazon Cognito Cognito-Konsole verwenden. Weitere Informationen finden Sie unter Managing Users in User Pools im Amazon Cognito Developer Guide.
Informationen zur Migration vorhandener Benutzer zu Amazon Cognito-Benutzerpools finden Sie im AWS-Blog Approaches for migration users to Amazon Cognito
Regionale Bereitstellung
Diese Lösung verwendet Amazon Cognito, das nur in bestimmten AWS-Regionen verfügbar ist. Daher müssen Sie diese Lösung in einer Region bereitstellen, in der Amazon Cognito verfügbar ist. Die aktuelle Serviceverfügbarkeit nach Regionen finden Sie in der regionalen AWS-Serviceliste
