Performancemessung, jetzt in echt

Guten morgen!

Guten morgen zusammen! Wie immer bin ich mit einem weinenden Auge in Berlin, und noch
einem weinenden. Eigentlich wollte ich gar nicht hier sein, sondern im Urlaub - da steckt
meine Frau mit den Zwillingen auch gerade, ich hab nur 2 Tage Urlaub vom Urlaub
bekommen. Mit einer direktverbindung von Florenz nach Berlin. Erstaunlich, dass es sowas
gibt. Also nicht die Direktverbindung, sondern funktionierende Flughäfen für Berlin.

Kekse

Ich werde heute abend wieder lecker italienisch Essen. Aber ich habe Euch ein paar Kekse
mitgebrachte, bitte einfach nehmen und weitergeben :-)

Dieser Talk ist
Keine Copy Paste Anleitung
Grundlagen Ideen FTW!
Wer etwas besser/mehr weiß:
Willkommen!
Präambel

Ihr?

Wer von Euch hat schon Erfahrungen mit Performancemessung gemacht?

ab(2), siege, httperf?

Welche Tools habt Ihr eingesetzt? Das sind die drei Klassiker, die praktisch jeder schon
einmal angewandt hat

Loadrunner, Webload,
OpenSTA, Jmeter, Grinder?

Daneben gibt es die dicken Tools, die erheblich mehr können und mehr für Szenarien
ausgelegt sind. Wer von Euch hat schon mit LoadRunner gearbeitet? Ich noch nicht :-)
Wäre es ok, wenn ich Euch nachher noch direkt ein paar Fragen dazu stelle?

OpenSource FTW!
Jmeter

Ich beschränke mich hier auf OpenSource, konkret auf Jmeter. Warum?
Weil es ok ist, kostenlos - nicht jeder will gleich mehrere tausend Euro Pro Nutzer ausgeben.

?Warum der Talk?
Aber warum mache ich diesen Talk. Das hat eigentlich einen ganz einfachen Grund.

We suck
at load testing.

Wir sind echt schlecht in Load Testing, meistens sind unsere Vorraussagen echt
unzuverlässig, und gerade wenn dann noch das Performance-Benchmarking auf einem
Testsystem und nicht auf dem echten Cluster stattﬁndet, dann kann man es fast vergessen.


But we sucked
even more
some years ago.Aber früher waren wir noch deutlich schlechter. Inzwischen haben wir gelegentliche Treffer,
und wenn auf einem echten System mit echtem Wissen über Nutzer testen dürfen, dann
kommen wir auch zur Garantie.

Learnings

Es geht also darum, was wir gelernt haben, neudeutsch learnings. Und da haben wir eine
ganze Menge gelernt.

Wir, das sind Mayﬂower, und das ist unser Logo in Bacon. Wir machen mit ca 70 Entwicklern
Webapplikationen, ein paar bekannte grosse Beispiele sind die SevenGames Plattform oder
die Telekom Cloud, aber auch vieles andere.

1 Werbeblock
4 Websites

Wir haben es schon erlebt dass in einem einzigen Werbeblock auf Pro7 4 Werbungen für
Webseiten kamen, an denen wir gebaut oder mitgebaut haben. Wer hat hier schon einmal
Fernsehwerbung für seine Plattform abbekommen? Gab das Traffic?

Genau.
Das gibt Trafﬁc.

Jepp, das gibt in der Tat Traffic.

Live-Events
Einmal-Aktionen
Heise-DDOS
Launches
Beratend sind wir auch häuﬁg mit dabei, etwa wenn ein eine neue populäre Plattform einen
Relaunch macht, oder wenn Live-Events passieren, besondere Einmalaktionen oder wenn man
über eine Heise-News geddosst wird. Mit Glück sind wir vorher mit dabei, meist aber
nachher, um beim Zusammenfegen der Scherben zu helfen.

5000
Nutzer parallel?
Wenn es gut läuft und wir vor den Problemen gefragt werden, oder wir selber mitbestimmen
dürfen, dann weiss der Kunde ungefähr, was kommt.

?
„Werden wir
Probleme
haben?“
Und er will wissen, ob es Probleme gibt oder nicht.

„Vermutlich nicht?“
Und, wenn wir als Entwickler ehrlich sind, können wir nur sagen:
Vermutlich nicht. Oder am besten ist jemand anders schuld: „Ich glaube, dass die Hardware
reicht.“

„ Es könnte schon klappen.“
Wir schliessen aber auch nicht aus, dass die Seite funktioniert.

„Wir können ja mal
Load -Testen“.
Am Ende kommt man dann auf die Idee, Load Testing zu machen.
Oder alles an Daten anschauen, was die Plattform so hergibt.


• ab
• siege
• httperf
ab -n 100 -c 50 http://mayﬂower.de/
Also nimmt man sich die Tools, mit denen man an einem Tag vorrankommen kann und guckt
nach.

„Vermutlich nicht.“
Wenn 50 Leute jeweils zweimal
auf die Homepage klicken ist alles gut.
Und wir sind ein bischen sicherer geworden, dass es keine Probleme gibt, aber noch nicht
ganz sicher.

Abandon the
transaction,
try later on computer
43 %
Go directly to a
competitor 12 %
Become more likely to
prefer a competitor 16 %
Log a complaint with
customer service 14 %
Der Kunde hat einen guten Grund, diese Aussage nicht zu mögen. Tealeaf, heute IBM, hat das
untersucht für mobile Apps. Was passiert, wenn die Performance nicht stimmt? 41% kommen
später wieder - sprich: 60% gehen verloren - und 12% wechseln direkt zu einem Mitbewerber.

„Vermutlich nicht.“
Vermutlich nicht reicht ihm also nicht als Aussage.

„Wo liegen unsere Limits?“
Schauen wir doch mal, wie wir ihm den Gefallen tun können, und grössere Sicherheit
bekommen können.

?„Werden die Ressourcen
reichen?“
Die Frage die dahinter steht ist eigentlich: „Werden die Ressourcen reichen?“
Wird das, was wir hier an Infrastruktur haben ausreichen?

Ressourcen
Webserver
Ressourcen: das sind erst mal alle Komponenten, die in so einer Webapplikation eine Rolle
spielen, also zB alle Server.

Ressourcen
Webserver
Datenbankserver

Ressourcen
Webserver
Datenbankserver
Caches

Ressourcen
Webserver
Datenbankserver
Caches
Message Queues

Ressourcen
Webserver
Datenbankserver
Caches
Message Queues
Proxies

Ressourcen
Webserver
Datenbankserver
Caches
Message Queues
Proxies
StorageRessourcen: das sind erst mal alle Komponenten, die in so einer Webapplikation eine Rolle

Ressourcen
CPU Request:
30-2000 ms CPU-Zeit
Und eigentlich ﬁnden diese Ressourcen innerhalb der Server statt. Die offensichtlichste ist
CPU, klar. CPU macht uns PHPlern im Regelfall nicht so viele Schmerzen, weil wir Shared
Nothing Architektur können, also einfach mehr kisten mit mehr PHPs drauf danebenstellen
können. Cloud wurde für uns erfunden. Eine moderne Applikation benötigt irgendwo
zwischen 30 und 2000 ms reine CPU-Zeit. Daneben gibt es noch Zeit, die der Kernel braucht,
um die CPU-Zeit nutzen zu können - etwa Kernel-Eigene Sys-Zeit, oder Zeit, die durch IO
oder IOWait draufgeht.

Ressourcen
CPU Request:
30-2000 ms CPU-Zeit
RAM Request:
ca 20 MB Resident Size
An zweiter Stelle kommt RAM. Da sind wir weder so richtig super skalierbar noch so richtig
Cloud. Ein gutes PHP kommt mit ca 5MB resident size aus - das ist der Speicher, der genau
für diesen PHP-Prozess belegt wird - kann bei Symfony2-Doctrine-Applikationen oder selbst
erfundene lustige Logik auch mal bis zu 50MB hochgehen. Dazu kommt natürlich der Ram,
der vom Kernel selbst, vom Betriebssystem und von eventuellen Ram-Caches benötigt wird.

Ressourcen
CPU Request:
30-2000 ms CPU-Zeit
RAM Request:
Storage Request:
0-X0.000 Ops
An dritter Stelle kommt Storage, klassischerweise lokal, zunehmend aber auch über das
Netzwerk. Hier gibt es je nach Caching- und Template-Logik zwischen - im Optimalfall - 0
echten Operationen, bishin zu mehreren zehntausend, die pro Request durchgeführt werden.
Wir haben schon Netzwerke gesehen, die nur über Metadaten-Abfragen für das Filesystem
saturiert wurden.

Ressourcen
CPU Request:
30-2000 ms CPU-Zeit
RAM Request:
Storage Request:
0-X0.000 Ops
Netzwerk Request:
0-500 Mbit
Das Netzwerk spielt mit den schnellen Netzen, die man heute in Rechenzentren ﬁndet meist
keine grosse Rolle. Aber genau deshalb verliert man es schnell aus den Augen, und plötzlich
reagiert das Filesystem nicht mehr, die Antwortzeiten der Datenbank werden schlechter, oder
das Caching funktioniert irgendwie nicht - und am Ende stellt sich das Netzwerk als Engpass
heraus.

Ressourcen
500 msCPU-Zeit
100 MBRam im Peak
1000Filesystem-Ops
2 MBNetwork Trafﬁc
Registration
Schauen wir uns doch mal einen Request auf dem Webserver an - etwa eine Registration. Der
Server ist aktueller Standard, 8 Cores, 16 GB RAM, Raid 1. Eine Registration ist ein dicker
Task, der bequem mal auf 100MB Ram hochgehen kann.

Ressourcen
0%
1,75%
3,5%
5,25%
7%
CPU RAM DISK NETWORK
2%
5%
0,7%
6,25%
Registration

Die Registration ist ein dicker Schritt im Regelfall, und dort fällt dementsprechend im
Webserver mehr Aufwand an. 500 ms CPU-Zeit verbrauchen 6,25% der zur Verfügung
stehenden Leistung, und da sind Betriebssystem-Kosten, IO-Wait etc noch nicht
herausgerechnet. Bei RAM sind die 100 MB zwar sehr viel - aber spielen bei den 16MB keine
Rolle, zumindest noch nicht.

ab -n 1000 .../register
0%
1,75%
3,5%
5,25%
7%
2%
5%
0,7%
6,25%
Registration

Schauen wir uns doch mal vor diesem Hintergrund das Benchmarking an, das man
normalerweise so macht. Was passiert denn, wenn ich hier einen ab mit 1000 Requests
gegenjage? Engpass ist CPU, DISK, Network und RAM sind mehr verfügbar als CPU.

ab -n 1000 .../register
Erwartung:
15 Requests/sec
Messung:
2 Requests/second
Was bekomme ich heraus, wenn ich das mache?
Der Test dauert 10 Minuten, und ich komme bei knappen 2 Requests pro Sekunde raus?
Sollten das nicht mindestens 15 oder so sein, wenn CPU der Engpass ist?
Die Ursache ist klar: Ich messe hier nur mit 1er Konkurrenz im Default, also werden 7 von 8
Cores nicht genutzt, und die Requests ﬁnden streng parallel statt.

Ressourcen
0%
25%
50%
75%
100%

Registration Video Streams Community Login
Praktisch ist der Traffic sehr viel durchwachsener. Das ist ein Beispiel aus der Praxis, wenn
auch vereinfacht dargestellt, wieder nur der Webserver.
Der Rechner war voll über CPU saturiert, sprich: die CPU-Load hat ihn getötet.

0%
25%
50%
75%
100%
Registration Video Stream Community Login
Ressourcen sind
Schweine
Was wir hier aber gelernt haben ist die Tatsache, dass Ressourcen Schweine sind.

0%
25%
50%
75%
100%
CPU
wird
RAMCPU wird zB zu RAM. Wenn die CPU nicht mehr genug Ressourcen hat, um alle Aufträge
parallel zu bearbeiten, dann steigt die Load über die Anzahl Cores, und die Requests werden
langsamer bearbeitet. Und das heisst auch, dass mehr Apachen nachdenken und solange
RAM belegen. Im Fazit steigt also der RAM-Verbrauch, weil die CPU nicht reicht.

0%
25%
50%
75%
100%
RAM
wird
StorageDas gleiche gilt auch noch weiter, wenn nämlich der RAM ausgeht. Was macht ein Rechner
dann? Genau, er beginnt zu Swappen, also Storage, und noch ﬁeser, schreibender Storage.
Und wenn der auf den Netzwerk liegt ... klar, dann wird er auch zu Network.

0%
25%
50%
75%
100%

Und auch das Verhalten der Nutzer ändert sich, wenn sich die Plattform anders verhält.
Hier war alle CPU ausgenutzt, mit der Folge, dass auch der Login deutlich langsamer war. So
langsam, dass man zum Teil in den Timeout des Reverse Cachings gelaufen ist.

Langsamer Login?
Reload ... Reload ... Reload ... Reload ...
Reload ... Reload ... Reload ... Reload ...

Und was passiert, wenn der Login langsam ist? Die Leute versuchen es häuﬁger, es gibt also
viele viele Klicks auf den Reload Button, aus ﬁesem Traffic wird also der No Point of Return.

Langsamer Login!
... weniger Nutzer in der Community
Aber nicht nur die Anzahl der Nutzer im Ressourcennutzungsproﬁl Login wird grösser - die
in der Community wird parallel kleiner.

Fazit: Das
Systemverhalten
beeinflusst das
Nutzerverhalten
beeinflusst das
Systemverhalten
Im Fazit beeinflussen sich also die Plattform und das Benutzerverhalten gleichmässig. Wie
gemein. Das heisst, dass Performancetuning unter Umständen in ganz neuen Problemen
resultieren kann - wie zum Beispiel in Nutzern, die auf einmal gerne auf der Plattform sind.

Ressourcen sind
Schweine
O(n)
Und nicht nur in der Beziehung sind die Ressourcen Schweine - sie verhalten sich nämlich
alles andere als linear, sondern sie machen bunte Linien. Wer hat hier Informatik studiert oder
kennt sich aus irgendeinem sonstigen Grund mit den Symbolen oben aus?

Komplexität
O(n)
Genau, Komplexität. Wofür gibt es Komplexität?
CPU, und weniger oft genannt: Speicher.
In der Praxis gilt das natürlich für jede Ressource, und nicht nur CPU und Speicher - und in
unserer Welt häuﬁg nicht entlang von Mengen, sonder entlang von Nutzerzahlen. Und
wichtiger: in der Praxis kann man Konstanten auch nicht einfach rauskürzen, weil Faktor
1000 mehr oder weniger Server ist konkret dann doch ein Unterschied. Und die Realität agiert
auch nach Konkurrenz, und nicht nur nach Datenmenge.

O(n)Konstant 100% Caching
Logarithmisch Gutes Caching
Linear Bildupload
Quadratisch Friend of a Friend
Exponentiell Optimales Routing
Und genau so können sich auch die einzelnen Ressourcen verhalten, je nach Art der Anfragen
die beim Server ankommen. Kann jemand sagen warum Facebook keine „über welche Wege
kann ich X kennen“-Logik anbietet?

O(n)
0
5
10
15
20
1 2 3 4 5 6 7 8 9 10
Konstant Logarithmisch Linear Quadratisch
Exponentiell
100 Nutzer != 2 * 50 Nutzer
Und genau da wirds hakelig mit dem Performance-Messen - weil ich kann eben nicht
einfache Multiplikation oder Addition machen. Wenn meine Logik im Schwerpunkt
logarithmisch ist, dann macht brauche ich mit 500 Nutzern nicht deutlich mehr Ressourcen
als mit 400. Wenn sie Quadratisch ist, dann brauche ich allerdings mit doppelt so vielen
Nutzern 4 mal so viele Rechner.

Fazit:
Ressourcen sind nonlinear
Ressourcen beeinﬂussen sich
und das Nutzerverhalten
Damit haben wir die klassischen Eigenschaften eines komplexen Systems, und können damit
nur so mittelgut vorhersagen, was passieren wird.

Wie man trotzdem gewinnt.

Die Rahmenbedingungen hören sich ja erst mal nicht gut an. Wer ist ebenfalls der Meinung,
dass dieses Verhalten von Plattformen eigentlich eine Unverschämtheit ist?
Wer ist der Meinung, dass schlechtes Wetter ebenfalls als Unverschämtheit zu werten ist?
Das Problem ist, an beiden Dingen können wir wenig dran ändern. Naja, wir könnten auf eine
Südseeinsel ziehen oder eine Plattform bauen, die niemand nutzen will. Besser ists aber, das
beste daraus zu machen.

Die Plattform
existiert schon.
Wenn die Plattform schon existiert: Hervorragend. Das macht es einfacher.

Die Plattform
existiert schon.
99,99%Und das ist auch genau die Stelle, an der wir die 99,99% Sicherheit bekommen können.

1 Top Seiten
nach Hits
cut -d' ' -f6,7 access.log |sort |uniq -c |sort -rn
Zunächst einmal muss ich die aktuelle Nutzung analysieren. Ich modelliere meinen Test also
so, dass er die gleichen Fingerprints im Accesslog hinterlässt wie der originale Traffic.

1 Top Seiten
nach Hits
Analyse in Excel
Ich will das gleiche Verhalten in meiner Simulation - also schaue ich mir an, wie viele
Requests ich dabei haben muss, um die gewünschte Zahl identischen Traffic zu erzeugen. Im
Beispiel habe ich mit der Simulation von 8 Requests nicht nur schon knappe 70%
übereinstimmung mit dem Originaltraffic, sondern auch schon 645000 Hits für erzeugt. Ich
gehe so weit herunter in meiner Simulation, bis ich bei der von mir gewünschten Prozentzahl
ankomme.

2Click Stream
Analyse
Aber diese Requests alleine machen ja nicht das Nutzerverhalten aus - manche Requests, im
obigen Beispiel fast alle, funktionieren zB nur nach einem Login.

2Click Stream
Analyse
write write
read write
read read
write read
read read
read read
Auch spielt bei der Nutzung von Ressourcen die Reihenfolge eine Rolle: wenn ich zum
Beispiel erst 2 mal Write und danach 4 mal Read auf die gleichen Daten habe, kann ich die
Daten 3 mal aus dem Cache liefern - wenn ich immer abwechseln Read und Write habe kann
ich nie aus dem Cache schöpfen.

2
Google Analytics
Der einfachste Weg ist wenn ich auf Google Analytics zugreifen kann, um an die Klickpfade
zu kommen

2
Log File Analyse
PWUM
Python Web Usage Mining
https://github.com/riivo/pwum
Das Python Web Usage Mining braucht sehr lange - und sehr viel Ram - für die Analyse von
Clickpfaden, ermöglicht dafür aber aber eine Automatische Erkennung von Mustern im
Nutzerverhalten

3
Nutzer mit ähnlichem Verhalten
„Personas“ in Agil
„Kohorten“ in Lean Startup
Gemeinsame Klickpfade gehen ok
Personas
Auf Basis der Clickstream baue ich Personas: Personas sind gedachte Nutzergruppen, die sich
jeweils ähnlich verhalten. Diese Personas teilen sich durchaus gemeinsame Klickpfade, und
ergeben in der Summe die Requests, die wir eben auf der Liste der Top-Requests gesehen
haben.

3

Personas
Wenn ich Personas habe ordne ich sie, ebenfalls wieder in Excel, den Requests zu - im
konkreten Fall bekommen die Nutzer, die ein bestimmtes Video anschauen, zu diesem Video
begleitend Informationen wie Texte, Schauspieler etc.
Am Ende habe ich eine Liste von Requests und deren Anzahl, die von den Personas
durchgeführt werden.

3 Personas
Und was ist, wenn man
keine Logﬁleshat?
„Wirklich, wirklich
gut schätzen“
Kommen wir noch mal zu dem Problem, wenn wir keine Logﬁles haben. Dann starten wir mit
guten Schätzungen - am besten sind welche von Branchenexperten, die mit vergleichbaren
Sites schon zu tun hatten. Damit kann man sehr daneben liegen. Wir haben beim Relaunch
einer Plattform mal selbst erlebt, dass der Marketingabteilung 70% des Traffics entgangen
sind.

3 Personas
Und was ist, wenn man
keine Logﬁleshat?
Test Pre- und
Post-Launch
Besser also, und auch eher im Sinne von Lean Startup - wenn man das ganze zweiteilt, einmal
in einen Pre- und einmal in einen Post-Launch-Test. Der erste stellt mit groben Annahmen
sicher, dass man Launchfähig ist, der zweite Validiert dann die Wachstumsstrategien auf
Basis der tatsächlichen Daten.

4 JMeter
Benötigte Requests
Klickpfade
Personas
Requests Pro Persona

Jetzt habe ich also die Requests, die ich zu einer guten Übereinstimmung brauche
Ich habe die Klickpfade, mittels der diese Requests angesteuert werden
Ich habe die Personas, die das Nutzungsverhalten meiner PLattform kennzeichnen
Und ich weiss welche Requests in welcher Häuﬁgkeit von den Personas aufgerufen werden
Ich kann also mit der Testmodellierung anfangen.

4 JMeter
Zunächst lege die die Basics an - für jede Persona eine HTTP Thread Gruppe - hier im Bild
Register, Video Stream, Community. Global im Testplan lege ich die HTTP Request Default
einstellungen an, mit dem kann man später schnell zwischen Installationen wechseln, und
konﬁguriere dort Protokoll, Server, Codepage und Konsorten.
Für jede Threadgruppe richte ich einen HTTP Cache Manager und einen Cookie Manager ein.
Unten links in der Workbench richte ich den Proxy Server ein.

4 JMeter
Dann konﬁguriere ich den Proxy, und richte ihn mir im lokalen Browser - zum Beispiel über
FoxyProxy - für meine Domain ein, und klick unten (hier nicht mehr zu sehen) auf Start.
Ich klicke unten auf „Add suggested Excludes“ um statische Files nicht mit aufzuzeichen.

4 JMeter
Unrat gibt es trotzdem, siehe hier die diversen nicht erkannten JS-Files. Wenn sie statisch
sind können sie im Regelfall gelöscht werden.

4 JMeter
Thinktime!
Und, weil ich es schon so oft gesehen habe - die Thinktime zwischen den Requests nicht
vergessen, niemand klickt 3 ms nach dem letzten Byte der Vorseite. Wir Humanoide, Doctor
Sheldon Cooper mal ausgenommen, brauchen Zeit. Am besten als einfacher Gaussian Timer.

4 JMeter
Throughput!
Alle die Requests, die in meinem Excel nicht mit jedem Lauf durchgeführt werden können
kann ich über den Troughput-Controller regulierern. Über die Thread- und Schleifenzahl
steuere ich, wieviele Requests pro Threadgruppe insgesamt durchgeführt werden, und mit
der Ramp-up-Time die Dauer des Laufs.
Über Assertions sichere ich ab, dass ich die korrekte Antwort bekommen habe. Das erkläre
ich hier nicht im Detail, weil es dazu tatsächlich viele gute Tutorials und ein Manual gibt.

4
überhaupt eine Antwort
die richtige Antwort
Geschwindigkeit
Aber was will man wissen und messen - zunächst einmal das offensichtliche, was einem auch
ab, siege, httperf und Konsorten mitteilen - gibt es überhaupt eine Antwort, und wenn ja,
was das eine, die ich habe wollten. Und natürlich - war sie so schnell, dass die Nutzer noch
am Rechner sind wenn die Antwort ﬁnal einmal ankommt.

4Summary Report
Die einfachste Variante der Beobachtung der der Summary Report, mit dem man diese Werte
erfährt - Fehler in Prozent, der Rest in Zeit mit Durchsatz, Mittelwert, Minimum/Maximum
und Standardabweichung.

4Summary Report
Diese Informationen helfen uns aber nur begrenzt weiter, weil sie uns nur den Boolean
„funktioniert“ oder „funktioniert nicht“ für das System under Test. Und eigentlich interessiert
uns vom funktionieren nur die grenzen desselben, also wann es aufhört zu funktionieren,
und dann warum.

5 Munin/Cacti
Zum Warum müssen wir aber wissen, was auf der anderen Seite passiert. Also was der oder
die Server gerade so machen. Am einfachsten ist das wenn man bereits eine funktionierende
Infrastruktur hat, die ohnehin schon alles aufzeichnet was man bekommen kann. Meist ist
das Cacti oder Munin, gelegentlich auch modernere Lösungen auf Node.js Basis, oder
enterprisiges a la Tivoli. Wichtig ist nur: ich habe die Daten, hinreichend granular, für das
System under Test.

5JMeter PerfMon
https://code.google.com/p/jmeter-plugins/
Wenn ich das noch nicht habe bietet mir JMeter glücklicherweise das was ich brauche. Bzw.
ein OpenSource-Projekt zur Erweiterung von JMeter.

5JMeter PerfMon
Dazu ist auf der Serverseite der Agent zu starten, der die Daten sammelt. das ist nur ein
einfaches Java-File, das trotzdem nicht viele Ressourcen frisst. Wenn der Daemon läuft - auf
einem oder allen Servern -

5JMeter PerfMon
gibt es auch das Pendant auf der Client-Seite. Hier gibt es ein Plugin, das schlicht in das Ext-
Verzeichnis von JMeter kopiert wird, und beim nächsten JMeter-Start dann mit perfmon -
aber nicht nur dem - zur Verfügung steht.

5JMeter PerfMon
Dort kann ich dann nicht nur meine Clients, sondern auch die Daten, die ich auf ihnen
Sammeln möchte anklicken.

5JMeter PerfMon
Und da gibt es praktisch alles, was ich so haben möchte - bishin zu einzeldaten für eine
bestimmte CPU auf dem System. Das gleiche gibt es natürlich auch für RAM, Swap,
Filesystem, Netzwerk etc.

6
O(n)
 Aber eigentlich wollen wir ja wissen, wie sich unsere Ressourcen über Zeit verhalten. Ob sie
im Quadrat, Exponentiell, linear oder - optimal - sich sublinear verhalten, also zB gut
gecached sind. Und zwar zur Bezugsgrösse User - denn meist wollen wir ja wissen, wie viele
wir konkurrierend können.

6

JMeter PerfMon
Graphen sammeln
Auch da bieten die JMeter Plugins Hilfe. Ich kann nämlich alle Daten, die ich in Graphen
darstellen kann - und da kann ich praktisch alle darstellen, über den schon bekannten
Metrics Monitor - im Composite Graph noch einmal zusammendübeln. Ich füge meinem
Testplan also alle interessanten Graphdaten zu, und am Ende den Composite Graph.

6

Composite Graph
An der Stelle knackt die Usability so ein bischen, ich muss nämlich zunächste einmal die
Simulation anstarten, damit jeder Graph ein bischen Daten hat - erst in dem Moment tauchen
sie im Composite Graph auf. Und wenn ich sie dort habe, kann ich sie dann auch in meinen
Kombinierten Graphen übernehmen.

6

Composite Graph
Und das sieht dann so aus - und hier habe ich zB genau eine Darstellung, mit der ich arbeiten
kann. Rot: Anzahl konkurrierende Nutzer, Grün: Netzwerk, Blau: CPU, Braun: Latency.

6

Und genau damit bekomme ich zB solche Graphen, mit denen ich sehe, dass ab ca 300
parallelen Nutzern das Antwortverhalten in Responsivität kaputt geht, aber immerhin
fehlerfrei kommt.

1) Relevante Requests
2) Klickfolgen
3) Personas
4) JMeter Testplan
5) Serverdaten
6) Reporting
ToDo
Noch mal zusammengefasst:
...
Eigentlich ganz einfach.


Glitches
Mit welchen Problemen muss ich dabei rechnen?

JMeter
skaliert
nicht.
Aber es gibt ein paar Pain Points: Jmeter selbst skaliert zB nicht.


https://github.com/oliverlloyd/jmeter-ec2
jmeter-ec2
Einfaches
Commandline Script
zur Nutzung von
jmeter in der Cloud.
Abhilfe schafft da Jmeter in der Cloud, namentlich jmeter-ec2, also einfache bash-basierte
Automatisierung von jmeter auf Basis der Amazon-ec2-Tools auf der Kommandozeile.
Nachdem ich meinen Testplan mit meinen Threads fertig habe, und die Konﬁgurationsdatei
auf meinen Amazon-Account angepasst habe kann ich loslegen.

jmeter-ec2
project=“pro“ percent=“20“
count=“3“ ./jmeter-ec2.sh
Einfach auf der Kommandzeile gestartet kann ich sagen, wie oft mein Testplan durchgeführt
wird, wieviel Prozent ich machen möchte - es gehen auch 1000 - und wieviele Maschinen ich
brauche. Das sind alles small Images, und dementsprechend kostet ein Testlauf im Regelfall
auch unter einem Dollar. Wir haben selbst gute Erfahrungen damit gemacht.


Alternativ gibt es das ganze auch in kommerziell, für die darf man auch Werbung machen,
weil bei denen regelmässig OpenSource herauspurzelt. Blazemeter hat ein schöneres Life-
Reporting, macht auch internationale Verteilung, und kann per Jenkins automatisiert werden.

Real != Test
Ungeteilte
Zentrale
Geteilte
Ressourcen
Das nächste Problem habe ich, wenn ich keine echte Testumgebung habe - also entweder
nicht die gleichen Server oder die gleiche Serveranzahl. Bei PHP-Servern habe ich es gut, die
sind ungeteilt, oder auch Shared Nothing, 8 Server können genau doppelt so viel User wie 4
Server. Für zentrale Ressourcen wie Datenbank, NoSQL oder Cache gilt das nicht. Das gleiche
gilt für geteilte Ressourcen wie SAN oder das Netzwerk. Hier kann ich nur mit Prognosen
arbeiten, denn ich kann nichts über die Ressourcennutzung der realen Ressourcen aussagen.

Real != Test
Identische
Ähnliche
Andere
Daten
Das gleiche gilt, wenn ich nicht auf die gleiche Datenbasis zurückgreifen kann, oder nicht auf
eine ähnliche. Auch in diesem Fall sind meinte Testaussagen nicht tauglich, weil ich nicht die
gleichen Ressourcen habe. Learning von uns: Testdatenerzeugung ist immer Major Pain und
deutlich Aufwand, aber meist führt kein Weg drumherum.

Eigene Limits
max_children
max_connections
buffers
kernel/tcp
Eigene Erfahrung: manchmal läuft man gegen Limits, ohne dass irgendeine Ressource
aufgebraucht wurde. Im Regelfall sind dann Limitierungen verantwortlich, die man selbst -
oder die Basiskonﬁguration - verursacht hat. Hier hilft es, sich einfach mal durch die
Konﬁgurationen zu klicken.

Performancemessung, jetzt in echt

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Andere mochten auch

Andere mochten auch (11)

Ähnlich wie Performancemessung, jetzt in echt

Ähnlich wie Performancemessung, jetzt in echt (20)

Mehr von Johann-Peter Hartmann

Mehr von Johann-Peter Hartmann (9)

Performancemessung, jetzt in echt