2012-04-25 9 views
8

Ich möchte die Anzahl der Threads für einen JMeter-Testplan zur Laufzeit ändern.Ändern Sie die Thread-Anzahl des Testplans in JMeter, zur Laufzeit

Ich habe mein Problem gegoogelt und eine vorgeschlagene Lösung gefunden, JMeter Plugins zu verwenden. Aber in dieser Lösung müsste ich die Thread-Gruppe vor dem Ausführen des Testplans einplanen, was ich nicht möchte. Ich fand auch another potential solution, die die Eigenschaft ändert, aber das Testplanverhalten zur Laufzeit nicht beeinflusst.

Letztlich versuche ich, die in einer Thread-Gruppe angegebene Thread-Nummer zu ändern und die Anzahl der Threads im aktuell ausgeführten Testplan sofort zu erhöhen oder zu verringern.

Ist das möglich?

+0

Können Sie Ihre Anforderungen beschreiben? Was genau möchten Sie erreichen, indem Sie die Anzahl der Benutzer-Threads dynamisch ändern? Was ist das Ziel Ihres Tests? –

+0

dynamische Anzahl der Erhöhung und Verringerung der Belastung der Web-App. Ich kann es über Jmeter Plugin tun, aber ich muss die Threads und Wartezeiten vordefinieren, die ich nicht will. –

+0

Ich verstehe das, aber warum? Sie müssen nicht warten, Sie können die Threads beliebig mit Plugins Ultimate oder Stepping Thread Group planen. Sie können Hunderte von ihnen in wenigen Sekunden hochfahren. Ich frage, weil ich noch nie von einer solchen Anfrage gehört habe und mich gefragt habe, warum jemand es brauchen würde. –

Antwort

3

Die kurze Antwort lautet: Nein, Sie können die Anzahl der Threads während der Laufzeit nicht dynamisch ändern. Jeder Thread-Zählwert wird nur einmal gelesen, wenn der Testplan zum ersten Mal kompiliert wird und nach diesem Punkt nicht erneut aufgelöst wird. Er bleibt also fest.

6

IMHO das ist nur eine ausgefallene Funktion, die keinen wirklichen Nutzen hat, wenn Sie richtige Leistungstests durchführen. Um eine relevante Testausgabe (Bericht) zu generieren, benötigen Sie repeatability und eine klar definierte Testmethodik und Szenarien. Um die Auswirkungen von Änderungen in der Anwendung/Server/Infrastruktur zu vergleichen, ist eine Wiederholbarkeit erforderlich.

Was meinst du mit

wir den Nutzer unserer Website vorhersagen können

Deshalb haben wir Performance-Tests auf dem ersten Platz zu tun. Um herauszufinden, was unser Anwendungs ​​/ Infrastruktur-Limit ist.
I.e. Die wichtigste Metrik, die Sie erstellen können, ist, wie sich die Antwortzeit Ihrer Anwendung ändert, wenn sich die Anzahl der parallelen Benutzer ändert. Aber nicht in der Laufzeit ändern sich unregelmäßig.

Mit jMeter plugins' Ultimate thread group können Sie jedes vorstellbare Szenario abdecken.

+0

mbonaci. was du sagst, ist richtig. Aber ich möchte wissen, dass es irgendeine Funktionalität gibt, die als LoadUI zur Verfügung stellt .. ?? Ich interessiere mich mehr dafür, weil JMeter mehr Funktionen als LoadUI bietet. –

+0

manchmal wäre es nützlich, mit den Werten spielen zu können, um einen Bereich zu finden, der für wiederholbare Tests nützlich sein wird. Ich habe Stunden damit verbracht, mit verschiedenen Werten für ultimative und stepping Threadgroups zu experimentieren, wo ich Minuten hätte machen können, wenn ich die Fähigkeit hätte. Nur weil Sie keinen Anwendungsfall haben, heißt das nicht, dass es keinen gibt. – CharlieS

+0

Was ist die Metrik, nach der Sie gesucht haben? Ich verstehe immer noch nicht, warum genau du das Feature gebraucht hast. Können Sie bitte Ihren Anwendungsfall näher erläutern? –

1

Sie können es basierend auf einer Variablen ändern, die Sie in einem Startthread festlegen. Siehe unten.

In Jmeter how do I set a variable number of threads using a beanshell sampler variable?

jedoch, sobald die Thread-Gruppe begonnen hat man es nicht ändern kann. Für den Typen, der diese Funktion nicht für nützlich hält, stimme ich nicht zu. Es gibt viele Arten von Belastungstests und sie haben nicht alle die gleiche Anzahl von Benutzern, die für die Dauer laufen. Hier sind nur zwei Beispiel Arten von Unternehmen Lasttests, die wir bei der Bank führen, wo ich arbeite:

  • Dauertest - gleiche Anzahl von Benutzern die ganze Zeit (möglicherweise mit einer kurzen Anlaufphase) läuft
  • Break Point Test - Rampe bis die Anzahl der Benutzer schrittweise, bis die Anwendung bricht
  • Spike-Test - lief mit einer konstanten Anzahl von Benutzern, sondern sporadisch
    Wurf in einer großen Anzahl von Benutzern

Ein Breakpoint-Test erhöht die Anzahl der Benutzer, bis die Anwendung abbricht (der Punkt ist, um zu sehen, wie hoch Ihre App skalieren kann). Sie können dies mit der Eigenschaft "ramp up period" der Thread-Gruppen erledigen.Wenn Sie die Hochlaufzeit auf 1000 und die Anzahl der Threads auf 100 einstellen, wird alle 10 Sekunden ein Thread hinzugefügt.

Spike-Tests sind wie Dauertests aber bei einigen Abständen in einer große Anzahl von Benutzern einloggen. Dies verwendet wird, um die Anwendungen Reaktionszeit während der Stoßzeiten Guage oder wie sie reagieren, wenn Sie ganz plötzlich eine große Anzahl von bekommen Benutzer (ein sehr reales Szenario).

Ich finde, dass Jmeter nicht alle Lasttest Szenarien behandelt, die in Enterprise-Belastungstests benötigt werden. Ein Workaround, den ich in Betracht ziehe, ist, einfach alle Threads zu starten, aber einen Weg zu finden, um einige von ihnen schlafen zu lassen. Sie können also die Anzahl der Threads auf 1000 setzen, aber 980 von ihnen schlafen lassen oder nichts tun. Dann, vielleicht, wenn die time_in_seconds% 5 == 0 (alle 5 Minuten) erlauben Sie den anderen Threads zu laufen - Simulation eines Spike-Tests. Die Idee ist, dass Sie die Threads fest auf 1000 programmieren können und immer 1000 Threads laufen lassen - aber sie müssen nicht immer etwas tun.

(mit anderen Worten können Sie wahrscheinlich einen Weg finden, aber man muss kreativ)

Update: Ich habe gerade dieses Plugin, die unterschiedlichen Arten von Tests ermöglicht. Habe es noch nicht ausprobiert, aber sieht vielversprechend aus: http://jmeter-plugins.org/wiki/ThroughputShapingTimer/

0

Sie können die Anzahl der Threads zur Laufzeit mit der Befehlszeile Option/ändern ...

Sie Funktionsaufrufe oder Variablenreferenzen auf Anwenderparameter verwenden können (was wiederum Funktionen sein könnten), oder Variablenverweise auf Variablen, die durch Funktionen früher im Test eingerichtet wurden. Es gibt mehr als eine Möglichkeit, dies zu tun.

Angenommen, Sie möchten die Anzahl der Threads in einem Testplan variieren können. Wählen Sie einen geeigneten Eigenschaftsnamen, sagen Sie group1.threads. Ersetzen Sie die Thread-Anzahl in der GUI (oder die JMX, wenn Sie sich tapfer fühlen!) Mit dem folgenden Funktionsaufruf:

Bitte legen Sie unten Eigenschaft in JMeter Thread-Gruppe wie folgt $ {__ Eigenschaft (group1.threads)}

wenn dann JMeter starten, definiert die Eigenschaft in der Befehlszeile:

jmeter -Jgroup1.threads = 10

+0

Dies ist keine Laufzeit, wenn Sie Jmeter mit einem Parameter zur Startzeit ausführen. Wie können Sie den Parameter ändern, während der Test läuft? –

2

Diese Funktion ist in der Tat nützlich, und überraschend schwierig zu implementieren, auch mit kommerziellen Tool wie Loadrunner. Ich würde es vergleichen mit dem Finden eines Lautsprechers maximale Lautstärke. Sie würden die Lautstärke manuell erhöhen, bis es anfängt zu knistern, und dann wieder leicht nach unten drehen, um diese maximale Lautstärke beizubehalten. Um die maximale Kapazität einer Anwendung zu finden, sollten Sie die Lautstärke aufdrehen, bis Fehler angezeigt werden, und sie dann etwas zurückfahren, um zu sehen, ob sie sich stabilisiert. Sie können diese Last dann beibehalten, um den Engpass zu finden.

Wie auch immer, um die Frage zu beantworten, was ich in der Vergangenheit getan habe, ist ein externer Einfluss, wie ein Dateiname oder ähnliches. Kombinieren Sie das dann mit der eindeutigen Threadreferenz, die Sie steuern können, welche Threads ausgeführt werden und welche gehalten werden (durch Pausieren oder Ähnliches).

Wenn Sie beispielsweise mit 100 Threads beginnen und dann eine Datei mit dem Namen '5.txt' an einem bestimmten Ort erstellen, können Sie Code hinzufügen, damit der Thread erkennt, dass der eigene Verweis gleich oder niedriger als der ist Nummer dann kann es laufen. Wenn nicht, dann fällt es in eine Pause. Am Anfang dieses Beispiels würden 5 Threads laufen und 95 würden pausieren. Sie können die Datei dann in '25 .txt 'umbenennen und die Threads 6 bis 25 beginnen zu laufen. Es würde auch anders funktionieren, wenn man es in '20 .txt 'umwandelt, würde das bedeuten, dass die Threads 21-25 erneut pausieren.

Der Schlüssel ist, genug Threads zu starten, um Ihre erwartete Spitze zu überschreiten.

+0

Dies ist eine der "Verkaufseigenschaften" von Soasta CloudTest, dass Sie die Lautstärke auf 11 on the fly ändern können. Also, wenn dies ein kritisches Merkmal ist, dann sollten Sie sich vielleicht CloudTest ansehen. –

0

Wir können den Benutzer unserer Website nicht vorhersagen.

Sicher kannst du. Dies ist, wofür die HTTP-Protokolle Ihrer bestehenden Site sind. Sie können auch Protokolle von Tools wie Omniture oder Ihren CDN-Protokollen verwenden. Wenn Sie sich die Kombination der tatsächlichen Benutzer-IP-Adresse, Anfrage- und Referer-Tags in den Protokollen ansehen, können Sie eine Traversal Map von jedem einzelnen Benutzer auf Ihrer Site erstellen. Sie werden in der Lage sein, die eindeutigen Seitenknoten eines bestimmten Geschäftsprozesses zu profilieren, um zu verstehen, wie oft ein bestimmter Geschäftsprozess eine Stunde dauert. Sie können die Aufgabe durch einen Blick auf den Trichter in Tools wie Omniture untersuchen. Wenn Sie Werkzeuge für diese Analyse benötigen, empfehle ich Splunk. Es ist einfach zu installieren und zu konfigurieren. Die Zeit zum Nutzen ist sehr schnell.

Je mehr Protokolldaten Sie verwenden, um das Profil zu erstellen, desto genauer können Sie sehen, was Benutzer während eines Tages/einer Woche/eines Monats/Spotverkaufs/Ende des Quartals/Jahresende/etc tun ... .Sie müssen zu einem Zeitpunkt tatsächliche tatsächliche frühere Zeiten kombinieren, um das Wachstum im Laufe der Zeit zu projizieren, da Sie Wachstum in Ihrem Leistungstestmodell berücksichtigen müssen.

Wenn Sie die Werte nicht richtig erhalten, ist der Wert Ihres Tests als Prädiktor dafür, was in der Produktion passieren wird/kann, ziemlich niedrig. Hierbei handelt es sich nicht um einen Fehler eines bestimmten Werkzeugs, sondern um einen Fehler in der Planung des tatsächlichen Lastmodells, das als Teil der Testanforderungen verwendet wird. Wenn Sie diese Modelle nicht bauen können, müssen Sie jemanden in Ihr Team ziehen, der das kann.

Diese Fähigkeit, ein gültiges Lastmodell unabhängig vom Werkzeug zu erstellen, ist der Unterschied zwischen Tests, die das Risiko und die Wurflast reduzieren.