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.

Erstellen Sie ein Testszenario

Die Erstellung eines Testszenarios umfasst vier Hauptschritte: Konfiguration der allgemeinen Einstellungen, Definition des Szenarios, Gestaltung von Verkehrsmustern und Überprüfung Ihrer Konfiguration.

Schritt 1: Allgemeine Einstellungen

Konfigurieren Sie die grundlegenden Parameter für Ihren Auslastungstest, einschließlich Testname, Beschreibung und allgemeinen Konfigurationsoptionen.

Identifizierung des Tests

Optionen für die Planung

Konfigurieren Sie, wann der Test ausgeführt werden soll:

Arbeitsablauf planen

Wenn Sie einen Test planen, findet der folgende Arbeitsablauf statt:

Live-Daten

Wählen Sie das Kontrollkästchen Live-Daten einbeziehen aus, um während der Ausführung Ihres Tests Echtzeit-Metriken anzuzeigen. Wenn diese Option aktiviert ist, können Sie Folgendes überwachen:

Die Live-Datenfunktion bietet Echtzeit-Diagramme mit Daten, die in Intervallen von einer Sekunde aggregiert werden. Weitere Informationen finden Sie unter Überwachung mit Live-Daten.

Schritt 2: Konfiguration des Szenarios

Definieren Sie das spezifische Testszenario und wählen Sie Ihr bevorzugtes Testframework aus.

Auswahl des Testtyps

Wählen Sie die Art des Belastungstests, den Sie durchführen möchten:

Traffic Shape-Modus

Wählen Sie aus, welche Seite die vom Test generierte Last steuert. Der Modus, den Sie auswählen, ändert die Felder, die die Konsole in Schritt 3: Traffic Shape anzeigt.

Native erfordert ein hochgeladenes Skript, sodass Sie es nicht auswählen können, wenn Sie den Testtyp Simple HTTP Endpoint wählen. Die vollständigen Definitionen und Anleitungen zur Auswahl des Modus finden Sie unter Traffic-Shape-Modi.

Konfiguration des HTTP-Endpunkts

Wenn „Simple HTTP Endpoint“ ausgewählt ist, generiert die Lösung einen JMeter-Testplan aus Ihrer Konfiguration und führt ihn mit der mitgelieferten Apache JMeter-Binärdatei aus. Konfigurieren Sie diese Einstellungen:

Testen Sie Framework-Skripte

Wenn Sie JMeter, k6 oder Locust verwenden, laden Sie Ihre Testskriptdatei oder ein ZIP-Archiv hoch, das Ihr Testskript und unterstützende Dateien enthält.

Für JMeter können Sie benutzerdefinierte Plugins in einen /plugins Ordner in Ihrem ZIP-Archiv aufnehmen.

Für Locust muss ein Testskript in einem ZIP-Archiv benannt werden. locustfile.py Um Python-Pakete von Drittanbietern zur Laufzeit in den Container zu installieren, fügen Sie dem Archiv eine requirements.txt Datei hinzu und optional ein packages Unterverzeichnis mit Wheel-Dateien, um sie ohne Internetzugang zu installieren. Weitere Informationen finden Sie unter Locust-Tests.

Dauer der Sicherheit (systemeigener Modus)

Wenn Sie den einheitlichen Modus auswählen, zeigt die Konsole neben dem Skript-Upload ein Feld für die Sicherheitsdauer an. Die Standardeinstellung ist 4 Stunden und die Höchstdauer ist 24 Stunden.

Im systemeigenen Modus beendet die Sicherheitsdauer einen Test, der länger als von Ihnen beabsichtigt ausgeführt wird, da Ihr Skript entscheidet, wann der Lauf abgeschlossen ist. Es ist eine Wache, kein Zeitplan. Wenn der Test nach Ablauf der Dauer noch läuft, stoppt die Lösung das Testframework. Es behält die Ergebnisse für den Abschnitt bei, der ausgeführt wurde, und zeichnet den Testlauf als abgeschlossen und nicht als fehlgeschlagen auf. Stellen Sie den Wert höher ein als die längste Ausführungsdauer, die das Skript voraussichtlich benötigen wird.

Schritt 3: Form des Verkehrs

Konfigurieren Sie, wie der Verkehr während Ihres Tests verteilt wird, einschließlich der Unterstützung mehrerer Regionen.

Shape-Modi für den Verkehr

Die Lösung bietet zwei Traffic-Shape-Modi: Standard und Nativ. Sie unterscheiden sich darin, welche Seite den Ladevorgang steuert: die Lösung oder das Skript, das Sie hochladen. Sie wählen den Modus in Schritt 2: Szenariokonfiguration aus, und er bestimmt, welche der folgenden Felder zutreffen.

Standard

Im Standardmodus hat die Lösung die Kontrolle über die Last. Sie legen die Anzahl der Fargate-Aufgaben pro Region, die Anzahl der gleichzeitigen virtuellen Benutzer pro Aufgabe, eine Anlaufzeit und eine Wartedauer fest. Die Lösung führt Ihren Test über das Taurus-Automatisierungsframework aus, das diese Werte in die eigenen Laststeuerungen des zugrunde liegenden Frameworks übersetzt. Taurus hat Vorrang vor dem Ladevorgang, den Ihr Skript deklariert. Daher wird ein k6-Optionsblock, eine Locust LoadTestShape - oder eine JMeter-Threadgruppe neu geschrieben oder ignoriert. Die virtuellen Benutzer einer Region sind die Anzahl der Aufgaben multipliziert mit der Parallelität für jede Aufgabe, und die Form ist dieselbe, unabhängig davon, welches Framework Sie gewählt haben. Auf diese Weise wurde jeder Test vor Version 4.3.0 ausgeführt, sodass sich früher erstellte Szenarien weiterhin genauso verhalten und keine Änderungen erforderlich sind.

Wählen Sie Standard, wenn die Lastform außerhalb des Skripts liegt und über die Konsole, die CLI oder einen Agenten festgelegt wurde. Standard ist der einzige Modus, in dem Sie eine genaue Anzahl virtueller Benutzer festlegen und das Ramp-up- und Hold-Shape ändern können, ohne das Skript zu berühren. Nur Standard unterstützt den Typ Simple HTTP Endpoint, bei dem die Lösung den Testplan für Sie generiert. Typische Anwendungen: eine Kapazitätsprüfung bei 500 bis 5.000 virtuellen Benutzern, eine nächtliche Regression, bei der 1.000 Benutzer zehn Minuten lang festgehalten werden, oder jeder Vergleich, für den eine identische Rampe erforderlich ist. Ihre Grenze liegt in der Ausdruckskraft. Alles, was Taurus nicht repräsentieren kann, ist hier nicht verfügbar, einschließlich mehrerer gewichteter Szenarien, Schwellenwerte pro Stufe und Ausführenden mit der Ankunftsrate.

Nativ

Im systemeigenen Modus hat Ihr Skript die Kontrolle über den Ladevorgang. Die Lösung führt die von Ihnen hochgeladene Datei unter der Framework-eigenen Befehlszeile aus: jmeter -n -tk6 run, oderlocust --headless. Es übergibt keine Ladeflags, sodass Ihr Skript die alleinige Autorität für den generierten Datenverkehr ist und die Lösung ihn niemals neu schreibt. Es gibt noch zwei Steuerelemente: die Anzahl der Fargate-Aufgaben, die pro Region gestartet werden sollen, und die erforderliche Sicherheitsdauer von bis zu 24 Stunden. Die Sicherheitsdauer ist ein Schutz vor einem Skript, das niemals beendet wird, kein Zeitplan. Wenn ein Test nach Ablauf der Dauer noch läuft, stoppt die Lösung das Framework, sammelt die Ergebnisse für den Abschnitt, der ausgeführt wurde, und zeichnet den Lauf als abgeschlossen und nicht als fehlgeschlagen auf. Jede Aufgabe wird als unabhängiger Framework-Prozess ohne Koordination zwischen den Aufgaben ausgeführt. Daher generiert eine Region für jede Aufgabe eine vollständige Kopie der deklarierten Last Ihres Skripts. Beispiel: Ein k6-Skript, das 200 virtuelle Benutzer enthält und auf fünf Aufgaben ausgeführt wird, setzt 1.000 virtuelle Benutzer auf das Ziel. Die Anzahl der Aufgaben ist daher die einzige Laststeuerung, die Native Ihnen bietet, und sie bewegt sich in einem Vielfachen dessen, was das Skript deklariert. Wenn Sie die Rampe, die Wartezeit oder die Anzahl der virtuellen Benutzer selbst ändern, müssen Sie das Skript bearbeiten.

Wählen Sie Nativ, wenn Sie ein Skript genau so ausführen möchten, wie es geschrieben wurde. Ein Skript, das bereits lokal oder in CI ausgeführt wird, läuft unverändert auf der Lösung, was der Hauptgrund dafür ist, nach Native zu greifen. Native bewahrt alles, was das Framework ausdrücken kann: k6-Szenarien, Stufen und Schwellenwerte; LoadTestShape Locust-Klassen und gewichtete Tasksets; JMeter-Timer und Threadgruppen. Wählen Sie es aus, wenn die Lastform Teil der Bedeutung des Tests ist und es wichtiger ist, sie originalgetreu zu reproduzieren, als sie von außen zu steuern. Typische Anwendungen: Wiederverwendung eines K6-Skripts aus einer Pipeline, ohne es neu zu schreiben, ein Spike-then-Recovery-Profil oder gewichtete Szenarien, die eine einzelne Parallelitätszahl nicht ausdrücken kann. Wenn das Framework so ausgeführt wird, wie es erstellt wurde, ergeben sich zwei Einschränkungen. Native erfordert ein hochgeladenes Skript, sodass Simple HTTP Endpoint nicht verfügbar ist. Locust-Skripte dürfen nicht gesetzt werdenprocesses, da die Lösung Anfragen nur zählt, wenn Locust als einzelner Prozess ausgeführt wird.

Wählen Sie einen Modus

Multi-Region Konfiguration des Datenverkehrs

Wählen Sie eine oder mehrere AWS-Regionen aus, um Ihren Lasttest geografisch zu verteilen. Konfigurieren Sie für jede ausgewählte Region:

Ermitteln Sie die Anzahl der Benutzer

Die Anzahl der Benutzer, die ein Container für einen Test unterstützen kann, kann bestimmt werden, indem die Anzahl der Benutzer schrittweise erhöht und die Leistung in Amazon überwacht wird CloudWatch. Sobald Sie feststellen, dass sich die CPU- und Speicherleistung ihren Grenzen nähert, haben Sie die maximale Anzahl von Benutzern erreicht, die ein Container für diesen Test in seiner Standardkonfiguration (2 vCPU und 4 GB Arbeitsspeicher) unterstützen kann.

Bei dieser Kalibrierung wird der Wert für Parallelität festgelegt, sodass er für den Standardmodus gilt. Die von ihm festgelegten Container-Grenzwerte gelten auch für den systemeigenen Modus. Dort erhöhen oder senken Sie die Last, die Ihr Skript deklariert, anstatt das Feld Concurrency festzulegen.

Prozess der Kalibrierung

Anhand des folgenden Beispiels können Sie mit der Bestimmung der Grenzwerte für gleichzeitige Benutzer für Ihren Test beginnen:

Wiederholen Sie die Schritte 1—3, wenn der Test die Ressourcengrenzen nicht überschritten hat. Optional können Sie die Containerressourcen erhöhen, um eine höhere Anzahl gleichzeitiger Benutzer zu ermöglichen. Dies führt jedoch zu höheren Kosten. Einzelheiten finden Sie im Entwicklerhandbuch.

Weitere Informationen zur Kalibrierung von Benutzern pro Engine finden Sie in der Dokumentation unter Kalibrierung eines Taurus-Tests. BlazeMeter

Tabelle der verfügbaren Aufgaben

In der Tabelle der verfügbaren Aufgaben wird die Ressourcenverfügbarkeit für jede ausgewählte Region angezeigt:

Informationen zum Erhöhen der Anzahl verfügbarer Aufgaben oder vCPUs pro Aufgabe finden Sie im Entwicklerhandbuch.

Dauer des Tests

Definieren Sie, wie lange Ihr Belastungstest ausgeführt wird. Die Konsole zeigt diesen Abschnitt nur im Standardmodus an. Im systemeigenen Modus bestimmt Ihr Skript, wie lange der Test läuft, begrenzt durch die Sicherheitsdauer, die Sie in Schritt 2: Szenariokonfiguration festgelegt haben.

Schritt 4: Überprüfen und Erstellen

Überprüfen Sie alle Ihre Konfigurationen, bevor Sie das Testszenario erstellen. Überprüfen:

Wählen Sie nach der Überprüfung Erstellen, um Ihr Testszenario zu speichern.

Verwaltung von Testszenarien

Nachdem Sie ein Testszenario erstellt haben, können Sie: