JMeter-Tipps

JMeter ist ein beliebtes Open Source-Tool für Lasttests mit vielen nützlichen Modellierungsfunktionen wie Thread-Gruppen-, Timer- und HTTP-Sampler-Elementen. Dieser Artikel ergänzt das JMeter-Benutzerhandbuch und enthält Richtlinien für die Verwendung einiger JMeter-Modellierungselemente zur Entwicklung eines Qualitätstestskripts.

Dieser Artikel befasst sich auch mit einem wichtigen Thema in einem größeren Zusammenhang: Angabe genauer Anforderungen an die Reaktionszeit und Validierung der Testergebnisse. Insbesondere wird eine strenge statistische Methode, die Konfidenzintervallanalyse, angewendet.

Bitte beachten Sie, dass ich davon ausgehe, dass die Leser die Grundlagen von JMeter kennen. Die Beispiele dieses Artikels basieren auf JMeter 2.0.3.

Bestimmen Sie die Hochlaufzeit einer Thread-Gruppe

Die erste Zutat in Ihrem JMeter-Skript ist eine Thread-Gruppe. Lassen Sie uns dies also zuerst überprüfen. Wie in Abbildung 1 dargestellt, enthält ein Thread Group-Element die folgenden Parameter:

  • Anzahl der Themen.
  • Die Hochlaufzeit.
  • Die Häufigkeit, mit der der Test ausgeführt wird.
  • Beim Start, ob der Test sofort ausgeführt wird oder bis zu einem geplanten Zeitpunkt wartet. In letzterem Fall muss das Thread-Gruppenelement auch die Start- und Endzeiten enthalten.

Jeder Thread führt den Testplan unabhängig von anderen Threads aus. Daher wird eine Thread-Gruppe verwendet, um gleichzeitige Benutzer zu modellieren. Wenn auf dem Clientcomputer, auf dem JMeter ausgeführt wird, nicht genügend Rechenleistung vorhanden ist, um eine hohe Last zu modellieren, können Sie mit der Funktion zum verteilten Testen von JMeter mehrere Remote-JMeter-Engines von einer einzigen JMeter-Konsole aus steuern.

Die Hochlaufzeit gibt JMeter an, wie lange es dauert, die Gesamtzahl der Threads zu erstellen. Der Standardwert ist 0. Wenn die Hochlaufzeit nicht angegeben wird, dh die Hochlaufzeit Null ist, erstellt JMeter sofort alle Threads. Wenn die Hochlaufzeit auf T Sekunden eingestellt ist und die Gesamtzahl der Threads N beträgt, erstellt JMeter alle T / N Sekunden einen Thread.

Die meisten Parameter einer Thread-Gruppe sind selbsterklärend, aber die Hochlaufzeit ist etwas seltsam, da die entsprechende Anzahl nicht immer offensichtlich ist. Zum einen sollte die Hochlaufzeit nicht Null sein, wenn Sie eine große Anzahl von Threads haben. Wenn zu Beginn eines Auslastungstests die Hochlaufzeit Null ist, erstellt JMeter alle Threads auf einmal und sendet sofort Anforderungen, wodurch der Server möglicherweise überlastet und, was noch wichtiger ist, die Last täuschend erhöht wird. Das heißt, der Server könnte überlastet werden, nicht weil die durchschnittliche Trefferquote hoch ist, sondern weil Sie alle ersten Anforderungen der Threads gleichzeitig senden, was zu einer ungewöhnlichen anfänglichen Spitzenhitrate führt. Sie können diesen Effekt mit einem JMeter Aggregate Report-Listener sehen.

Da diese Anomalie nicht wünschenswert ist, besteht die Faustregel zur Bestimmung einer angemessenen Hochlaufperiode darin, die anfängliche Trefferquote nahe an der durchschnittlichen Trefferquote zu halten. Natürlich müssen Sie den Testplan möglicherweise einmal ausführen, bevor Sie eine angemessene Anzahl ermitteln können.

Aus dem gleichen Grund ist auch eine große Hochlaufzeit nicht angemessen, da die Spitzenlast möglicherweise unterschätzt wird. Das heißt, einige der Threads haben möglicherweise noch nicht einmal begonnen, während einige anfängliche Threads bereits beendet wurden.

Wie stellen Sie sicher, dass die Hochlaufzeit weder zu klein noch zu groß ist? Erraten Sie zuerst die durchschnittliche Trefferquote und berechnen Sie dann die anfängliche Hochlaufperiode, indem Sie die Anzahl der Threads durch die erratene Trefferquote dividieren. Wenn beispielsweise die Anzahl der Threads 100 beträgt und die geschätzte Trefferquote 10 Treffer pro Sekunde beträgt, beträgt die geschätzte ideale Hochlaufzeit 100/10 = 10 Sekunden. Wie kommen Sie auf eine geschätzte Trefferquote? Es gibt keinen einfachen Weg. Sie müssen das Testskript nur einmal ausführen.

Zweitens fügen Sie dem Testplan einen Listener für aggregierte Berichte hinzu (siehe Abbildung 2). Es enthält die durchschnittliche Trefferquote jeder einzelnen Anfrage (JMeter-Sampler). Die Trefferquote des ersten Samplers (z. B. eine HTTP-Anforderung) hängt eng mit der Hochlaufzeit und der Anzahl der Threads zusammen. Passen Sie die Hochlaufzeit so an, dass die Trefferquote des ersten Samplers des Testplans nahe an der durchschnittlichen Trefferquote aller anderen Sampler liegt.

Drittens überprüfen Sie im JMeter-Protokoll (in JMeter_Home_Directory / bin), ob der erste Thread, der beendet wird, tatsächlich beendet wird, nachdem der letzte Thread gestartet wurde. Der Zeitunterschied zwischen den beiden sollte so weit wie möglich voneinander entfernt sein.

Zusammenfassend wird die Bestimmung einer guten Hochlaufzeit durch die folgenden zwei Regeln geregelt:

  • Die Trefferquote des ersten Samplers sollte nahe an der durchschnittlichen Trefferquote anderer Sampler liegen, wodurch eine kleine Hochlaufzeit verhindert wird
  • Der erste Faden, der endet, endet tatsächlich nach dem Start des letzten Fadens, vorzugsweise so weit wie möglich voneinander entfernt, wodurch eine große Hochlaufzeit verhindert wird

Manchmal widersprechen sich die beiden Regeln. Das heißt, Sie können einfach keine geeignete Hochlaufzeit finden, die beide Regeln erfüllt. Ein trivialer Testplan verursacht normalerweise dieses Problem, da in einem solchen Plan nicht genügend Sampler für jeden Thread vorhanden sind. Daher ist der Testplan zu kurz und ein Thread beendet seine Arbeit schnell.

Benutzer denken an Zeit, Timer und Proxyserver

Ein wichtiges Element, das bei einem Auslastungstest berücksichtigt werden muss, ist die Denkzeit oder die Pause zwischen aufeinanderfolgenden Anforderungen. Verschiedene Umstände verursachen die Verzögerung: Der Benutzer benötigt Zeit, um den Inhalt zu lesen, ein Formular auszufüllen oder nach dem richtigen Link zu suchen. Wenn die Denkzeit nicht richtig berücksichtigt wird, führt dies häufig zu stark verzerrten Testergebnissen. Beispielsweise erscheint die geschätzte Skalierbarkeit, dh die maximale Last (gleichzeitige Benutzer), die das System aushalten kann, gering.

JMeter bietet eine Reihe von Timer-Elementen zur Modellierung der Denkzeit. Es bleibt jedoch die Frage: Wie bestimmen Sie eine geeignete Denkzeit? Glücklicherweise bietet JMeter eine gute Antwort: das JMeter HTTP Proxy Server-Element.

Der Proxyserver zeichnet Ihre Aktionen auf, während Sie eine Webanwendung mit einem normalen Browser (z. B. FireFox oder Internet Explorer) durchsuchen. Darüber hinaus erstellt JMeter einen Testplan, wenn Sie Ihre Aktionen aufzeichnen. Diese Funktion ist für verschiedene Zwecke äußerst praktisch:

  • Sie müssen keine HTTP-Anforderung manuell erstellen, insbesondere nicht die langwierigen Formularparameter. (Nicht-englische Parameter funktionieren jedoch möglicherweise nicht richtig.) JMeter zeichnet alles in den automatisch generierten Anforderungen auf, einschließlich ausgeblendeter Felder.
  • In den generierten Testplan enthält JMeter alle vom Browser generierten HTTP-Header für Sie, z. B. User-Agent (z. B. Mozilla / 4.0) oder AcceptLanguage (z. B. zh-tw, en-us; q = 0,7, zh-) cn; q = 0,3).
  • JMeter kann Timer Ihrer Wahl erstellen, bei denen die Verzögerungszeit entsprechend der tatsächlichen Verzögerung während des Aufnahmezeitraums eingestellt wird.

Mal sehen, wie JMeter mit der Aufnahmefunktion konfiguriert wird. Klicken Sie in der JMeter-Konsole mit der rechten Maustaste auf das WorkBench-Element und fügen Sie das HTTP-Proxyserverelement hinzu. Beachten Sie, dass Sie mit der rechten Maustaste auf das WorkBench-Element und nicht auf das Testplan-Element klicken, da die Konfiguration hier für die Aufzeichnung und nicht für einen ausführbaren Testplan vorgesehen ist. Mit dem HTTP-Proxyserver-Element können Sie den Proxyserver des Browsers so konfigurieren, dass alle Anforderungen über JMeter gesendet werden.

Wie in Abbildung 3 dargestellt, müssen mehrere Felder für das HTTP-Proxyserverelement konfiguriert werden:

  • Port: Der vom Proxyserver verwendete Überwachungsport.
  • Ziel-Controller: Der Controller, auf dem der Proxy die generierten Samples speichert. Standardmäßig sucht JMeter im aktuellen Testplan nach einem Aufzeichnungscontroller und speichert die Proben dort. Alternativ können Sie ein beliebiges im Menü aufgeführtes Steuerelement auswählen. Normalerweise ist die Standardeinstellung in Ordnung.
  • Gruppierung: Wie Sie die generierten Elemente im Testplan gruppieren möchten. Es stehen mehrere Optionen zur Verfügung, und die sinnvollste ist wahrscheinlich "Nur den ersten Sampler jeder Gruppe speichern". Andernfalls werden auch URLs aufgezeichnet, die in eine Seite eingebettet sind, z. B. für Bilder und JavaScripts. Möglicherweise möchten Sie jedoch die Standardoption "Proben nicht gruppieren" ausprobieren, um herauszufinden, was JMeter im Testplan genau für Sie erstellt.
  • Zu schließende Muster und auszuschließende Muster: Helfen Sie dabei, einige unerwünschte Anforderungen herauszufiltern.

Wenn Sie auf die Schaltfläche Start klicken, wird der Proxyserver gestartet und beginnt mit der Aufzeichnung der empfangenen HTTP-Anforderungen. Bevor Sie auf Start klicken, müssen Sie natürlich die Proxy-Server-Einstellungen Ihres Browsers konfigurieren.

Sie können einen Timer als untergeordnetes Element des HTTP-Proxyserver-Elements hinzufügen, wodurch JMeter angewiesen wird, automatisch einen untergeordneten Timer als untergeordnetes Element der von ihm generierten HTTP-Anforderung hinzuzufügen. JMeter speichert die tatsächliche Zeitverzögerung automatisch in einer JMeter-Variablen namens T. Wenn Sie also dem HTTP-Proxyserver-Element einen Gaußschen Zufallszeitgeber hinzufügen, sollten Sie $ {T} in das Feld Konstante Verzögerung eingeben (siehe Abbildung 4) Eine weitere praktische Funktion, die Ihnen viel Zeit spart.

Beachten Sie, dass ein Timer dazu führt, dass die betroffenen Sampler verzögert werden. Das heißt, die betroffenen Stichprobenanforderungen werden nicht gesendet, bevor die angegebene Verzögerungszeit seit der letzten empfangenen Antwort verstrichen ist. Daher sollten Sie den vom ersten Sampler generierten Timer manuell entfernen, da der erste Sampler normalerweise keinen benötigt.

Bevor Sie den HTTP-Proxyserver starten, sollten Sie dem Testplan eine Thread-Gruppe hinzufügen und dann der Thread-Gruppe einen Aufzeichnungscontroller hinzufügen, in dem die generierten Elemente gespeichert werden. Andernfalls werden diese Elemente direkt zu WorkBench hinzugefügt. Darüber hinaus ist es wichtig, dem Aufzeichnungscontroller ein HTTP-Anforderungsstandardelement (ein Konfigurationselement) hinzuzufügen, damit JMeter die in den HTTP-Anforderungsstandards angegebenen Felder leer lässt.

Stoppen Sie nach der Aufzeichnung den HTTP-Proxyserver. Klicken Sie mit der rechten Maustaste auf das Recording Controller-Element, um die aufgezeichneten Elemente in einer separaten Datei zu speichern, damit Sie sie später abrufen können. Vergessen Sie nicht, die Proxy-Server-Einstellung Ihres Browsers fortzusetzen.

Geben Sie die Anforderungen an die Antwortzeit an und validieren Sie die Testergebnisse

Obwohl dies nicht direkt mit JMeter zusammenhängt, sind die Angabe der Antwortzeitanforderungen und die Validierung der Testergebnisse zwei wichtige Aufgaben für Lasttests, wobei JMeter die Brücke ist, die sie verbindet.

Im Kontext von Webanwendungen bezieht sich die Antwortzeit auf die Zeit, die zwischen der Übermittlung einer Anforderung und dem Empfang des resultierenden HTML-Codes verstrichen ist. Technisch gesehen sollte die Antwortzeit die Zeit umfassen, die der Browser benötigt, um die HTML-Seite zu rendern. Ein Browser zeigt die Seite jedoch normalerweise Stück für Stück an, wodurch sich die wahrgenommene Antwortzeit verkürzt. Darüber hinaus berechnet ein Lasttest-Tool in der Regel die Antwortzeit, ohne die Renderzeit zu berücksichtigen. Aus praktischen Gründen für Leistungstests übernehmen wir daher die oben beschriebene Definition. Fügen Sie im Zweifelsfall der gemessenen Reaktionszeit eine Konstante hinzu, z. B. 0,5 Sekunden.

Es gibt eine Reihe bekannter Regeln zur Bestimmung der Antwortzeitkriterien:

  • Benutzer bemerken keine Verzögerung von weniger als 0,1 Sekunden
  • Eine Verzögerung von weniger als 1 Sekunde unterbricht den Gedankenfluss eines Benutzers nicht, es wird jedoch eine gewisse Verzögerung festgestellt
  • Benutzer warten weiterhin auf die Antwort, wenn sie sich um weniger als 10 Sekunden verzögert
  • Nach 10 Sekunden verlieren Benutzer den Fokus und beginnen etwas anderes zu tun

Diese Schwellenwerte sind bekannt und ändern sich nicht, da sie in direktem Zusammenhang mit den kognitiven Eigenschaften des Menschen stehen. Obwohl Sie Ihre Anforderungen an die Antwortzeit gemäß diesen Regeln festlegen sollten, sollten Sie sie auch für Ihre spezielle Anwendung anpassen. Zum Beispiel hält sich die Homepage von Amazon.com an die oben genannten Regeln, aber da sie ein stilistischeres Aussehen bevorzugt, wird ein wenig Reaktionszeit geopfert.

Auf den ersten Blick scheint es zwei verschiedene Möglichkeiten zu geben, die Anforderungen an die Antwortzeit festzulegen:

  • Durchschnittliche Reaktionszeit
  • Absolute Reaktionszeit; Das heißt, die Antwortzeiten aller Antworten müssen unter dem Schwellenwert liegen

Das Festlegen der Anforderungen an die durchschnittliche Antwortzeit ist unkompliziert, aber die Tatsache, dass diese Anforderung Datenschwankungen nicht berücksichtigt, ist störend. Was ist, wenn die Reaktionszeit von 20 Prozent der Proben mehr als das Dreifache des Durchschnitts beträgt? Beachten Sie, dass JMeter die durchschnittliche Antwortzeit sowie die Standardabweichung für Sie im Listener "Graph Results" berechnet.

Andererseits ist die absolute Antwortzeitanforderung ziemlich streng und statistisch nicht praktikabel. Was ist, wenn nur 0,5 Prozent der Proben die Tests nicht bestanden haben? Dies hängt wiederum mit der Variation der Stichproben zusammen. Glücklicherweise berücksichtigt eine strenge statistische Methode Stichprobenvariationen: die Konfidenzintervallanalyse.

Lassen Sie uns die grundlegenden Statistiken überprüfen, bevor wir fortfahren.

Der zentrale Grenzwertsatz

Der zentrale Grenzwertsatz besagt , dass wenn die Populationsverteilung Mittelwert μ und eine Standardabweichung σ aufweist, so ist für ausreichend großen n (> 30), wobei die Stichprobenverteilung des Probenahme Mittelwert etwa normal ist, mit einem Mittelwert μ Mittelwert = μ und eine Standardabweichung σ Mittelwert = σ / √n.

Beachten Sie, dass die Verteilung des Stichprobenmittelwerts normal ist. Die Verteilung der Stichprobe selbst ist nicht unbedingt normal. Wenn Sie Ihr Testskript also mehrmals ausführen, ist die Verteilung der resultierenden durchschnittlichen Antwortzeiten normal.

Die folgenden Abbildungen 5 und 6 zeigen zwei Normalverteilungen. In unserem Kontext ist die horizontale Achse das Stichprobenmittel der Antwortzeit, verschoben, sodass das Populationsmittel am Ursprung liegt. 5 zeigt, dass in 90 Prozent der Fälle die Abtastmittel innerhalb des Intervalls ± Z & sgr; liegen, wobei Z = 1,645 und & sgr; die Standardabweichung ist. Abbildung 6 zeigt den 99-Prozent-Fall mit Z = 2,576. Für eine gegebene Wahrscheinlichkeit, sagen wir 90 Prozent, können wir den entsprechenden Z-Wert mit einer normalen Kurve nachschlagen und umgekehrt.