In dieser Folge tauchen wir in das Thema Load Testing ein.
Wir klären, warum es so wichtig ist, was die verschiedenen
Testarten wie Stress oder Spike Testing bringen und welche
zentralen Metriken du kennen musst.
Außerdem sprechen über praktische Open Source und
Enterprise Tools Monitoring Strategien, Fehler, die du
vermeiden solltest und wie du Load Testing in cicd Pipelines
und vielleicht auch deinen Alltag integrierst.
Lass uns gemeinsam Performance Probleme schon vor dem Release
aufführen. Hallo und herzlich Willkommen zu
Folge 131 des To do Developer Podcasts mit Robin Manuel Thiel
und mir malte Lantin. Robin Manuel ist Cloud und AI
Architekt bei Microsoft und Ich bin Solutions Engineer bei
github. Den Podcast machen wir natürlich
privat in unserer Freizeit und geben hier unsere persönliche
Meinung und Erfahrung an euch weiter und tauschen uns
natürlich ganz viel untereinander aus und auch in
dieser Folge haben wir wieder ein Thema, was dich Robin Manuel
in den letzten Wochen intensiv beschäftigt hat, nämlich das
Thema Low Testing, das. Ich habe mich natürlich in das
Thema auch eingelesen, aber ich hoffe, dass ich auch aus deiner
Praxiserfahrung, die ganz frisch ist, extrem viel lernen kann.
Und ich denke auch für unsere Zuhörerinnen und Zuhörer ist das
Thema super spannend. Genau.
Bevor wir aber einsteigen, müssen wir noch danke sagen und
zwar an euch. Wir haben wieder Kaffee von euch
bekommen und das erste Dankeschön ist ein ganz
Besonderes. Die Julia hat nämlich Jubiläum,
die hat uns seit einem Jahr. Jetzt schon mit einem Kaffee Abo
unterstützt. Man kann bei uns bei bei mir
Coffee auch quasi so einfach regelmäßig einen Kaffee ausgeben
und das wollen wir natürlich nicht unvergessen lassen, da ist
Julia ja seit einem Jahr dabei. Ganz ganz herzlichen Dank.
Vielen Dank dafür. Das ist ganz super.
Ansonsten hat uns der Sebastian noch 3 Kaffee ausgegeben diese
Woche und er hat uns einen kleinen Gruß dagelassen und sich
für den Podcast bedankt, der ihm die Skills gibt, um mit gesundem
Ai Halbwissen jederzeit seinen CTO in den Wahnsinn zu treiben.
Von daher sind wir super happy, dass wir Mehrwert stiften können
und in eurer Firma zum Entertainment der
Führungsmannschaft beitragen können.
Sehr, sehr gerne. Ja, dann steigen wir mal ein Low
Testing, warum macht man das eigentlich?
Also der Hauptgrund ist so ein bisschen, dass die meisten
Performance Probleme oft unentdeckt bleiben, bis so eine
Applikation wirklich mal unter Last steht und das liegt
natürlich zum einen daran, dass wenn man eine Applikation
entwickelt, entweder alleine oder in einem kleinen Team
natürlich die Last erstmal überschaubar ist, weil ich dann
vielleicht irgendwie ein 2 Tests dagegen schieße und mal so ein
bisschen in. Ja, so ein bisschen Smoke
Testing eigentlich mache was da genau die Unterschiede sind.
Kommen wir noch mal zu, aber eigentlich so ein bisschen das
ja nur als Einzelperson austesteste und es oft nur
Theorie ist wie sich mein System eigentlich verhält, wenn da mal
wirklich hunderte oder tausende User gleichzeitig darauf
zugreifen und genau das wird beim Low Testing jetzt mal
simuliert. Und wir wollen natürlich
sicherstellen, dass unser System auch jederzeit die Erwartung
unserer Nutzer erfüllt. Wir haben dort.
Nicht nur die Erwartungshaltung, die irgendwie alle von uns
haben, dass irgendwie die Anwendung funktioniert, sondern
wir haben auch vielleicht vertraglich vereinbarte
Garantien, die wir unseren Kunden gegeben haben, was halt
Response Zeiten betrifft. Was SL as für die Verfügbarkeit
betrifft, und die wollen wir natürlich nicht verletzen.
Genau. Man kann also sagen, dass
eigentlich so Low Testing eine Teilmenge von Performance
Testing ist, weil eigentlich testen wir die Performance, das
ist ja dann auch das, wo wir die SL AS wahrscheinlich drauf
haben, also dass wir quasi eine gewisse gewisse Antwortzeiten
einhalten, aber natürlich auch eine gewisse Up Time einhalten
können, also eine gewisse Fehlerrate niedrig halten, denn.
Es kann ja sein, dass wir schnell antworten, aber halt nur
für 99% der User und der eine Prozent der User, der jetzt
vielleicht irgendwie noch zusätzlich dazu kommt, der
kriegt dann halt extrem viele Fehler, weil unsere Systeme
überlastet, überlastet sind und eigentlich dieses Wissen,
wieviel Last man eigentlich erträgt.
Das erlangt man am Ende vom Low Testing aber natürlich auch so
ein bisschen Hilfe bei der Skalierbarkeit und der
Kapazitätsberechnung. Bei dem Thema Low Testing, da
kommen ja auch relativ schnell andere.
Begriffe aus dem Bereich des Performance Testings ins Spiel.
Vielleicht sprechen wir die mal ganz kurz durch, um einfach auch
die Unterscheidung noch mal klar zu machen.
Ich glaube ein paar Sachen hattest du gerade am Anfang
schon genannt, aber ich glaube es macht Sinn, das noch mal ein
bisschen zu erklären, was da die Unterschiede sind zwischen jetzt
Low Testing und anderen Performance testing Arten.
Zunächst einmal vielleicht Stress.
Testing, was ist denn der Unterschied zwischen Load und
Stress Testing, weil beides hat ja mit Last zu tun.
Ja, genau, es ist auch, glaube ich, alles so Arten von Load
Testing unter dem normalen Load Testing versteht man es erst mal
so, die Anwendung unter der normalen Last.
Also ich schaue so okay was habe ich, wie viele Anwender habe ich
ungefähr gleichzeitig auf meiner Plattform, das kann ja sich auch
bei einer globalen Plattform zum Beispiel verteilen, dadurch,
dass einfach Tag und Nachtzeiten und Zeitzonen unterschiedlich
sind, so. Es kann sein, dass ich eine
Business Anwendung habe, die am Wochenende viel weniger genutzt
wird als unter der Woche. Das heißt, ich gucke mir so ein
bisschen aus, was ist denn so die normale erwartete Last, also
vielleicht auch so die höchste normale erwartete Last, die ich
irgendwie habe und teste mein System unter dieser Last.
Und beim Stresstesting wird diese normale Lastgrenze jetzt
einfach mal überschritten, das heißt, wir gucken, wie verhält
sich mein System denn wenn morgen doppelt so viele Leute
auf meine Plattform gehen, das kann im E Commerce Fonds können
das Sachen sein die die absehbar sind, teilweise sowas wie.
Das ist Black Friday. Oder steht das
Weihnachtsgeschäft an und dann muss ich natürlich gucken, wie
verhält sich meine Anwendung darauf hin.
Es kann aber auch Dinge sein, die ich vielleicht gar nicht
abschätzen kann. Irgendein Influencer hat sich
über mein Produkt gesprochen und auf einmal habe ich eine völlig
unerwartete Last auf meinem SARS.
Tool vielleicht auch oder sowas und.
Oder hier in diesem weltberühmten To do Cast haben
wir irgendwie ein Tool erwähnt und auf einmal muss der
Hersteller oder die Herstellerin natürlich mit extrem viel mehr
Last rechnen und diese Dinge, quasi das System, eigene Systeme
unter Stress zu setzen und zu gucken, wo sind die Bruchpunkte,
das testet man dann halt im Stresstesting das ist nichts was
ich normalerweise brauche, weil normalerweise gucke ich ja, wie
verhält sich mein System unter der normalen Last.
Ich will aber trotzdem wissen, was würde denn passieren?
Wenn morgen 3040 100% mehr User und Userinnen auf meine
Plattform kommen. Ja, und das ist ja eng
verbunden, auch mit dem sogenannten Spike Testing, wo
wir plötzliche Lastspitzen haben, das heißt im üblichen Low
Testing nehmen wir unsere normalen.
Nutzungspatterns, die wir kennen, von unserer Plattform
und testen dagegen beim Spike Testing testen wir, was
passiert, wenn jetzt wirklich ganz plötzlich die Last
hochgeht, das kann so was sein, was du gerade erwähnt hattest,
dass irgendwo mein Produkt erwähnt wird, vielleicht, dass
auch irgendwo in der Presse, in den Medien irgendwas auftaucht
und dann ganz unerwartet extrem viel Last auf der Plattform ist.
Und da kommt nämlich noch zusätzlich halt der Zeitfaktor
mit rein und. Werden, das heißt, es ist eine
plötzliche Lastspitze und nicht das, was wir gerade besprochen
hatten. Genau das ist dann vor allem
auch das, wo ich meine, die Skalierung meines Systems teste,
und zwar nicht kann mein System skelieren, sondern wie schnell
kann mein System skelieren, wie schnell kann ich diese
plötzliche Last abfangen? Dann gibt es noch das Thema, was
halt eher auf die lange Zeit ausgelegt, sogenanntes Endurance
Testing. Da haben wir hohe Last über
einen langen Zeitraum und da achten wir halt plötzlich auf
andere Dinge. Dinge vielleicht weniger die
klassischen Fehler, die auftreten, wenn ein System
überlastet ist, sondern wir schauen uns vor allen Dingen an,
wie zum Beispiel die Speicherauslastung aussieht,
weil wir haben unsere Anwendung jetzt wirklich über Monate und
Jahre laufen, und es kommt immer wieder vor, dass wir dann auch
irgendwo kleine Memory Leaks haben und dann irgendwie uns der
Speicher vollläuft und wir dann irgendwann in fehlerverhalten
Reinlaufen, was wir aber nur sehen, wenn wir über einen
längeren Zeitraum die Anwendung auch beobachten.
Genau und ähnlich dazu ist so ein bisschen das Volume Testing.
Das ist das Gegenteil, da müssen wir gar nicht unbedingt auf
einen längeren Zeitraum testen, sondern dann testen wir auf
einmal mit sehr hohem Volumen, das sind hauptsächlich dann
große Datenmengen, also das ist ja, wenn ich jetzt irgendwie
eine Speicherlösung anbiete und jemand lädt da Petabytes an
Daten hoch und ich habe auf einmal sehr, sehr, sehr, sehr
große Datenmengen, die in meine Datenbank geschrieben werden, so
was testet man auch, und das ist natürlich alles Last fürs
System, deswegen fällt das auch alles so unter diese Load
testing Kategorie. Und in der Regel ist es so, also
bei uns. Ich kann ja mal ein bisschen ein
bisschen ausholen, wo jetzt bei mir auch das Interesse dafür
herkam. Ich war in einem Projekt, da
haben wir Lasttests eingeführt, eben auch aus den Gründen, die
du eben genannt hast. Malte, wir mussten, müssen eben
gewisse SL AS quasi einhalten, und wir müssen sicherstellen
können, dass wir mit dem System, was wir gebaut haben, auch die
erwartete Last, die dann irgendwann auf uns zukommt, wenn
das System live ist, abdecken können, und das müssen wir halt
immer wieder garantieren, auch regelmäßig garantieren und.
Und wir haben halt uns für einen Low Testing Service entschieden.
Wir machen das nicht alles selber.
Kommen wir nachher noch mal zu was es da für Services gibt und
innerhalb dieses Low Testing Services haben wir verschiedene
Arten von Tests, das heißt Wir haben mal einen Spike Test.
Wir haben einen Stresstest und so weiter gebaut, das heißt es
fällt glaube ich schon alles in diese Low Testing Kategorie mit
rein, sind aber einfach unterschiedliche Tests die man
baut. Wir.
Damit kommt man ja auch so ein bisschen zu den Gründen, warum
man das auf jeden Fall machen sollte.
Du hattest es ja gerade erwähnt, ihr habt da Performance
Garantien für eure Kunden und das macht man ja nicht irgendwo
aus Nettigkeit, sondern man hat da auch finanzielle
Verpflichtungen dahinter und man möchte natürlich Kosten
vermeiden, wenn man bestimmte. Zu sagen bricht, und das ist
teilweise wirklich auch teuer. Es gibt zahlen aus der
Industrie, die Halt von irgendwie einem fünfstelligen
Betrag pro Stunde rechnen, wenn eine Anwendung ausfällt.
Das hängt natürlich davon ab, was für eine Art von Anwendung
ich habe und wie viele Kunden ich habe, aber da kommen
natürlich verschiedene Faktoren dazu, wenn ich eine E Commerce
Plattform habe, habe ich vielleicht keine SL as, aber auf
der anderen Seite gehen mir dann will ich massiv umsetzen.
Verloren, wenn gerade in Zeiten steigender Last plötzlich meine
Plattform für Kunden nicht verfügbar ist, weil im E
Commerce kommt es dann ganz schnell vor, wenn ich jetzt
irgendwie nicht Amazon bin, wo die Leute immer wieder kommen,
dass die Leute dann, wenn die Seite nicht richtig
funktioniert, dann halt zum nächsten Händler wechseln und
daher kommen halt auch diese hohen Zahlen, die man da
ermittelt und gerade auch bei größeren Unternehmen kann das
auch. Auch schon dann relativ schnell
in die Millionen gehen, wenn es regelmäßig wirklich zu fehlender
Verfügbarkeit der Anwendung kommt.
Ja, Amazon hat mal gesagt, dass sie $13000000 pro Stunde Ausfall
verlieren würden. Allein an Umsatz ist natürlich
schon Crazy, wahrscheinlich auch der Grund warum ich, warum ich
Amazon noch nie offline gesehen habe, wäre ja auch glaube ich
sehr schlechtes Marketing für ADAV US.
Aber auch halt Sachen, die jetzt gar nicht, gar nicht in einen
genauen Euro oder einen Dollar umzurechnen sind, sondern auch
so. Es gibt Studien, die sagen, man
kann, man kann diese Conversion Verluste messen mit jeder
Sekunde ladezeitverzögerung zum Beispiel, die ich habe, einfach
weil Leute, die Lust verlieren, auf meiner Plattform unterwegs
zu sein oder tatsächlich auch einfach das Vertrauen in die
Plattform verlieren. Ich finde, es wirkt immer so ein
bisschen ja. So ein bisschen merkwürdig
bisschen fishy, wenn eine Plattform irgendwie sehr lange
lädt, dann wird das immer so ein bisschen altbacken.
Also neben den wirklich zahlen, die man messen kann an Umsatz,
der verloren geht, wenn eine Plattform offline oder langsam
ist, fand ich das auch spannend, dass es da auch so eine
psychologische Komponente gibt und dass man sich das eigentlich
nicht leisten kann, weil auch gerade so langsame oder
unresponsive Apps, es muss ja gar nicht immer nur e Commerce
sein, aber auch natürlich Kunden wieder auf, ja vielleicht dazu
motivieren, sich mal Alternativen oder die Konkurrenz
anzuschauen. Und eine gute Performance kann
auch zu einer höheren Kundenbindung führen.
Also es gibt wie gesagt, es gibt diese psychologische Komponente,
dass wir alle natürlich Apps, die, die gut funktionieren mögen
und auf der anderen Seite natürlich auch wirklich
messbarer Umsatz uns durch die Lappen geht, oder oder halt
nicht nur Umsatz, sondern wir wirklich teilweise auch
Vertragsstrafen zahlen müssen, wenn wir zum Beispiel für andere
hosten oder sowas, dann haben wir natürlich auch mit SL AS,
die wir auch vertraglich vereinbart haben, wir.
Das heißt, wir haben die finanziellen Aspekte und dann
natürlich indirekt auch so Themen wie Kundenzufriedenheit,
die zu finanziellen Ausfällen führen können.
Und dann kommen wir natürlich zu den ganz praktischen technischen
Gründen, die am Ende natürlich auch irgendwelche
wirtschaftlichen Hintergründe haben.
Aber ich glaube, gerade für uns, die wir uns mit der Technik
beschäftigen, gibt es halt dann auch noch ganz klare technische
Gründe, warum man mal einen Loadtest machen muss und den
regelmäßig wiederholt. Weil man natürlich auch die
Skalierbarkeit, die technische Skalierbarkeit der Anwendung
auch planen muss. Das heißt, ich kann jetzt
irgendwie mir akademisch Gedanken machen, wie ich meine
Infrastruktur aufbaue, dass sie möglichst skalierbar ist, aber
wie konkret ich diese dann in der Praxis skaliere, in welcher
Geschwindigkeit, bis zu welchen Grenzen, sehe ich halt nur unter
realer oder simulierter Last während eines Lasttests.
Und nur dann kann ich auch meine Kapazitätsgrenzen erkennen.
Mein Infrastrukturbedarf auch entsprechend konfigurieren,
damit meine Anwendung dann auch im Ernstfall entsprechend
skaliert. Das heißt, auf der technischen
Ebene brauche ich das natürlich hier, um das ganze Vorzuplanen.
Ja, bis dahin ist es halt nur theoretisch.
Und jetzt, wenn ich eine richtige Last mal drauf setze,
dann erkenne ich vielleicht auch irgendwelche Fehler, die ich
vorher gar nicht gesehen habe und auch hier, je früher ich
natürlich so eine Fehlererkennung habe, je früher
ich natürlich irgendwie merke, ich habe irgendwo Performance
Bottle next und die jetzt einmal idealerweise auch noch vor dem
Go Life oder sowas identifizieren kann oder
irgendwelche Memory Leaks oder vielleicht auch Code
ineffizienten Aufdecke, die halt ich halt nur unter Last sehen
kann, zeigen ja auch schon gerade wo wir vorhin aber über
die Zahlen gesprochen haben, wie wichtig ist das, ist das
vielleicht auch schon. Recht früh in den
Entwicklungsprozess mit einzubinden.
Also wir haben jetzt bei unseren Lasttests zum Beispiel
herausgefunden, dass die Systeme und für sich allein gesehen alle
ganz gut funktioniert haben, aber dann natürlich auch unter
Lastabhängigkeiten wieder auf andere Systeme haben.
Also wir machen auch Micro Services, und da hatten zum
Beispiel viele Systeme. Eine Abhängigkeit auf einen
rechtszentralen Service, der für sich ganz gut funktioniert.
Aber wenn diese ganzen Systeme gleichzeitig unter Last stehen,
halt alle auf diesen einen Service, das heißt der hat
eigentlich eine überdimensionale Last, weil die alle auf diesen
einen zentralen Service irgendwie zugegriffen haben und
damit zum Beispiel dann eine Code Ineffizienz erkennen können
und sowas. Und diese frühe Fehlererkennung
bevor man irgendwie. Einen Go live hat, bevor man
sich jetzt irgendwie den Markt mit seiner neuen Plattform
präsentiert. Also einmal würde ich diesen
Lasttest auf jeden Fall vorher fahren und wie du gerade schon
gesagt hast, die Skalierbarkeit auch entsprechend so
dimensionieren. Ich glaube ich würde, wenn ich
in einer in so einer Hyperskala Cloud bin, auch vor dem Go live
gerne mal deutlich über überskalieren, dass zumindest so
der Erste der Ersteindruck von meiner Plattform sehr sehr gut
ist. Und da kann ich ja immer noch
hinten raus, dann gucken, wie ist denn die tatsächliche Last
das? Kann man sich ja sogar in den
meisten Clouds kann ich ja für wenige Tage einfach ein paar wms
dazu buchen. Für meinen Go Life oder für
meine Marketing Kampagne, weil ich es mir eben nicht erlauben
kann. Und am Ende sind wir ja hier
auch in einem developer Podcast. Und auch das Thema Load Testing
hängt so ein bisschen mit der Entwicklerzufriedenheit
zusammen, weil ich glaube niemand.
Niemandem macht es Spaß, irgendwie firefighting zu
betreiben. Im Ernstfall dann Logs
durchzugehen und zu sagen, Hey, wo sind jetzt hier die Bottle
next, weil irgendwo im laufenden Betrieb die Anwendung
zusammengebrochen ist. Wir in Memory Leaks reinlaufen,
sondern wir wollen halt uns auf die Entwicklung von neuen
Funktionalitäten konzentrieren und da auch als Team möglichst
effizient arbeiten und nicht immer wieder rausgerissen werden
wegen irgendwelchen Problemen in Produktion und dementsprechend.
Vorsorgen mit Low Testing, um nachher weniger Probleme zu
haben. Und da kommt natürlich das ganze
Thema Integration in den Entwicklungsprozess ins Spiel.
Wir haben nachher noch mal ein bisschen mehr Informationen, wie
ich das Ganze dann auch in meine cicd Pipelines reinbringe, um
halt auch wirklich regelmäßig diese Tests durchführen zu
können, damit es einfach ein integrierter Teil meiner
Entwicklung ist. Es gehört halt einfach dazu,
dass. Dass die Funktionalitäten, die
ich die Fahr auch entsprechend skalierbar sind, so dass ich
zumindest die Normallast im besten Fall auch
außergewöhnliche Last problemlos abwickeln kann.
Ja, das ist doch mal so ein low Test bauen, also zumindest
soweit das hier irgendwie Audio only in so einem Podcast möglich
ist. Und dafür ist es glaube ich
wichtig, dass wir uns erstmal so ein bisschen die Anatomie von so
einem Low Test angucken und so ein bisschen die.
Uns die Konzepte anschauen, da wird von Virtual Usern von Rent
Times gesprochen, von through pod, von Test engines und so.
Deswegen lass uns doch mal kurz die Zeit nehmen, da so ein
bisschen durchzugehen. Also es gibt, das ist, glaube
ich ganz wichtig, es gibt alles, startet mit so einem virtuellen
User oder Virtual User, wenn man es irgendwie in Englisch macht
und dieser dieser virtuelle User, dem gibt man quasi ein
bestimmtes Verhalten mit, das heißt man definiert wie man das
vielleicht auch bei einem End to End Test oder sowas machen
würde, einfach welche Endpunkte werden in welcher?
Reihenfolge aufgerufen in der Regel in den meisten Loadtests
sind es halt eben irgendwelche Endpunkte, die über das Web
aufgerufen werden. So ein User muss sich
wahrscheinlich erst mal irgendwie einloggen und ja quasi
seine Credentials gegen den Token eintauschen und dann habe
ich eben diesen User, der der eine einzelne Verbindung
simuliert, warum virtueller User a?
Weil es natürlich kein echter User ist und b weil wir nachher
noch so ein bisschen sehen werden, dass das innerhalb der
Infrastruktur auch noch mal verteilt wird, da kann ich dann
mal so Entscheidungen treffen wie.
Kriegt jeder von diesen virtuellen Usern wirklich auch
eine eigene virtuelle Maschine oder teilen die sich teilweise
auch eine virtuelle Maschine? Das hat Netzwerktechnik
natürlich auch Auswirkungen, ob die beide über die gleiche IP
Adresse zum Beispiel auf meinen Service zugreifen oder ob die
Hardware auf der dieser Low Test dann läuft, vielleicht auch
irgendwann mein bottle net ist und gar nicht mehr genug
Netzwerk Requests rausschicken kann, weil vielleicht.
Die Netzwerkleitung, wo meine Hardware dann angeschlossen ist,
das ist das gar nicht mehr hergibt.
Aber deswegen man wird, wenn man so Loadtests baut oder sich dann
mit dem Thema informiert beschäftigt, immer auf das
Konzept von virtuellen Nutzern stoßen.
Und wenn wir jetzt hier über die Nutzer und die Last der Nutzer
nachdenken, sind es zum einen natürlich die ganz menschlichen
Nutzer, die wir am Ende auf unserer Anwendung haben.
Das sind die Kunden unserer E Commerce.
Webseite oder irgendwelche anderen User unserer Apps.
Aber natürlich muss ich auch andere Dinge ein bisschen im
Hinterkopf haben und das hier in meinen Tests mit Abbilden.
Das können dann irgendwelche Bots sein, die meine Seite
parsen, irgendwelche Search engine Crawler, die durch meine
Seite durchgehen und zusätzliche Last erzeugen.
Ich habe letztens von einem Fall gehört, wo auf einer E Commerce
Seite die jemand in Europa aufgesetzt hat, regelmäßig
irgendwelche Crawler aus Asien kamen und den gesamten Wahnsinn.
Katalog Gecrawlt haben. Ob das jetzt etwas ist, was
vielleicht dazu führt, dass ich am Ende irgendwie asiatische
Billigkonkurrenz habe, weiß ich nicht, aber mit solchen Dingen
muss ich rechnen, das heißt, ich habe nicht nur die menschlichen
User, sondern ich habe erwartete und unerwartete Maschinen, User,
die nachher auch auf meine Webseite zugreifen, wir hatten
in der Vergangenheit auch über die entsprechenden.
Agents der ganzen Ki Anbieter gesprochen, die irgendwie
regelmäßig das Webcrawlen und auch solche Dinge muss ich
natürlich für meine Grundlast mitberücksichtigen, weil gerade
in so einer. Preproduction Umgebung, wo ich
das häufig teste, da greifen meistens solche Bots ja nicht
zu. Das heißt, ich muss das dann
natürlich mitberücksichtigen, aber wenn wir so einen
virtuellen User haben, ist das tatsächlich meistens eher so das
Äquivalent der Menschen, aber das andere kommt natürlich noch
dazu und das muss ich natürlich mitberücksichtigen.
Ja genau das ist dann natürlich auch noch mal ein anderer Case.
Also das sind beides virtuelle User, wenn ich das Halt erlauben
möchte, dass irgendwelche Crawler Bots da ist, allein
schon irgendwie der Google Search.
Indexer, der ab und zu auf meine Seite kommt, den den will ich ja
wahrscheinlich haben und die haben natürlich aber auch noch
mal ein anderes Nutzerverhalten, also die werden ja nichts in den
Warenkorb legen oder irgendwelche Zahlungsdaten
angeben, sondern die werden ja wahrscheinlich erlesend auf
meine Anwendung zugreifen und so habe ich natürlich eben diese
beiden Pattern, und die muss ich natürlich auch, wie du richtig
gesagt hast, beide als virtuelle User simulieren.
Dann. Schauen wir, was machen die
virtuellen User auf meiner Seite und in der Regel ist es nicht
so, dass User alle gleichzeitig von einer Sekunde auf die andere
auf diese Seite gehen, sondern die verteilen sich so ein
bisschen über einen Zeitrahmen und wir simulieren so eine
sogenannte Ramp Up Time, das heißt von den ersten Usern oder
unserer Grundlast bis hinzu der erwarteten Spitzenlast.
Bauen wir das nach und nach auf, um wirklich auch beobachten zu
können, wie sich unsere Anwendung verhält, während die
Last langsam ansteigt. Das ist insbesondere dann
interessant, wenn meine Anwendung auch automatisch
skaliert bei einer Anwendung, die keine skalierende
Infrastruktur hat, ist es natürlich auch wichtig zu sehen,
wie im Laufe der Zeit sich das Verhalten meiner Anwendung
verändert und ob es dann irgendwo vielleicht so einen
Punkt gibt, wo die Anwendung die Last nicht mehr bedienen kann,
aber gerade wenn ich irgendwie skalierbare und.
Komponenten habe. Dann ist natürlich wichtig zu
beobachten, wie während dieser Ramp Zeit von meinem ersten User
oder einer Basislast, die ich auf der Plattform habe bis zu
der Maximalanzahl der User, die ich konfiguriert habe, wie sich
das ganze System in diesem Zeitraum verhält.
Genau da denke ich natürlich einfach einen realistischen
Lastwachstum ab. Also wenn ich jetzt keine
Ahnung, ich habe 20 virtuelle User und ich mache eine Ramp
time von 2 Minuten, also von 120 Sekunden, dann würde es 120
Sekunden dauern bis alle 20 virtuellen User aktiv sind und
dann eben diese diese Skripte und patterns halt ja Daten
abzuarbeiten die ich da eben definiert habe und das soll eben
eine realistische Last darstellen, das kann man auch
wieder umgekehrt machen, man kann auch so eine.
So eine Ramp down Time machen, wo man irgendwie sagt gleich
gegen Abend hin, wo mehr und mehr Leute dann irgendwie meine
Plattform wieder verlassen, skaliert da meine Plattform
gleich wieder auch richtig zurück.
Also du hast ja gerade schon richtigerweise Skalierung
angesprochen, vielleicht habe ich ja keine Ahnung, ich gehe
davon davon aus, ich mache ein kubuliertes Cluster oder sowas,
wo ich natürlich auch Kosten sparen will, wenn abends weniger
Leute auf meiner Plattform ist und das heißt auch sowas kann
ich dann natürlich messen, skaliert die Plattform wieder
anständig zurück mit einem Abfall von Usern die ich da
drauf habe. Und dann gehe ich natürlich hin
und muss schauen, wie verhält sich die Anwendung für meine
virtuellen User, also was sind zum Beispiel die Response Times,
also die Antwortzeiten, also wie lange dauert es, bis ein User
nach seinem Request seine Antwort erhält und du hast es
gerade angesprochen, irgendwie Anwendungen die.
Lange Response Zeiten haben die sind per se so ein bisschen
fragwürdig für die User in der Regel.
Von daher ist es natürlich wichtig, wenn User auf die
Webseite geht, dass dann entsprechend niedrige Response
Zeiten auch bei hohen User zahlen ermöglicht sind.
Ja, dagegen über steht so ein bisschen die Latency, das wird
auch oft mitgemessen, also werden die Response Zeit so ein
bisschen wie lange braucht denn mein Gesamtrequest, also bis der
letzte der letzte Teil der Antwort da ist, ist die Latency
so ein bisschen was ist. Wie lange braucht es, bis das
erste Mal antwortet? Das ist vor allem, wenn
vielleicht Antworten gestreamt werden oder sowas relevant bei
unseren Low Tests haben wir jetzt aber in der Regel fast
immer nur die komplette Response Time gemessen, also wie lange
dauert es bis ein request vollständig abgearbeitet ist und
wieder da ist, weil wir dadurch natürlich auch so ein bisschen
inkludieren wie lange Rödel das Backend.
An der Antwort also da kannst du dann halt auch eben so Code,
Ineffizienzen oder irgendwelche Überlastungen des Backends
besser mit tracken. Legacy ist glaube ich eher was,
was man auch was auf der Netzwerkebene relevant ist.
Also wenn ich da irgendwie mal mein Bottleneck vermute, würde
ich wahrscheinlich eher auf die Latency gucken, aber für uns ist
jetzt die Response Time spannend und ja das alles kombiniert.
Gibt mir dann eigentlich den Three pod.
Das ist das was ich wissen will. Also Three pod ist requests per
second. Wie viele von diesen Requests
kann ich denn wirklich jetzt pro Sekunde gleichzeitig stellen und
abarbeiten und das ist dann eben genau das, was halt für mich
dann am Ende relevant ist. Was ich in der Regel auch Messe,
dass ich schaue wieviel wieviel Last kann ich denn pro Sekunde
aushalten, wie viele User gleichzeitig können meine
Anwendung benutzen? Letzter Begriff, der häufig
auftaucht und genannt wird, ist die sogenannte Test Engine.
Das ist die entsprechende Infrastruktur, auf der dann
meine Testskripte ausgeführt werden, und im Idealfall ist
diese auch. Weltweit verteilt.
Wenn ich eine weltweite Userbase habe oder zumindest über
verschiedene Standorte im gleichen Land im gleichen
Kontinent, um halt dann halt auch realistisches Userverhalten
zu simulieren. Das heißt, ich führe das dann
jetzt nicht von dem gleichen Server aus, auf dem irgendwie
meine Anwendung gehostet wird, weil das natürlich kein
realistisches Szenario ist und auch von meiner Clientmaschine
ich kann natürlich auch diese Skripte von meinem Developer
Client laufen lassen, aber am Ende ist das ja auch kein
realistisches Land. Lastverhalten, sondern ich
sollte das in der Regel über vielleicht irgendeinen Low
Testing Service auf verschiedene Systeme ausrollen und dann von
da aus durchspielen und dann die Metriken wiederum einsammeln.
Viele der Services, die ich auch vielleicht als saas Dienst
nutzen kann, bieten das Out of the Box an, ansonsten auch mit
Open Source Tools kann ich das dann selber aufsetzen, indem ich
mir halt einfach. 23 locations buche und dann meine Tests halt
verteilt ausführe und dann nachher die Metriken
zusammenführe. Vielleicht bei den Metriken, da
ist ein paar Erfahrungswerte, was sinnvoll ist, wenn man
erfolgreiches Low Testing machen möchte.
Genau das ist ein bisschen der nächste Punkt.
Ich habe das jetzt alles aufgesetzt, meine virtuellen
User laufen los und setzen jetzt Last auf mein System und.
Und deswegen ist es wichtig, dass man sich natürlich, bevor
man sich so einen, bevor man so einen Test macht, jetzt in den
Metriken überlegt, die ja, wann ist denn so ein Test
erfolgreich, was ist auch eine Failure kriteria und da schaut
man sich eigentlich so immer die durchschnittliche Antwortzeit an
und die längste Antwortzeit. Aber wichtig hier für eine
realistische Bewertung würde ich immer auf die durchschnittliche
Antwortzeit gucken, also auf das weiß nicht 90 9599 perzentil.
Also gucken, wo, wo bewegen sich denn so 99% meiner Requests,
weil die Erfahrung hat gezeigt, du hast immer mal irgendwie
einen Ausreißer oder einen Netzwerk request irgendwo hängen
geblieben und hat irgendwie unerwartet viele Hobbs gemacht.
Das ist dann ja auch, wenn man sich da wirklich da Tausende
Requests gleichzeitig drauf setzt, nicht immer
aussagekräftig. Was war denn der längste, den
darf ich mir meistens auch irgendwie anzeigen, aber ich
gucke natürlich was an, wie ist die Erfahrung für 99% meiner
User in dieser response Zeit und.
Und darüber hinaus natürlich aber auch so ein paar
Systemressourcen dann von meinen Systemen, also in meinem Cluster
ist das natürlich gerade so, Speicherverbrauch und CPU
Auslastung, das ist aber auch die Netzwerklatenz zwischen
meinen Systemen, also zwischen meinem meinem Backend System und
der Datenbank, oder ich habe noch irgendwelche API Gateways
und so weiter und. Und natürlich dann die
Errorrate. Die sollte natürlich relativ
gering bleiben, das sind irgendwelche Errors, die im
Backend natürlich immer auftreten können.
Kein System ist perfekt, die dann auch der User vorne
mitkriegt, also alles was kein 200 er Response auf meiner auf
meinem Rest Layer ist, wo die API dann eben irgendwas wie ein
500 er Fehler oder sowas zurückgibt, die will ich
natürlich gering halten. Du hattest gerade schon gesagt,
wir müssen uns jetzt überlegen, wann schlägt unser Low Test
fehl. Natürlich, wie bei allen anderen
Tests, die wir durchführen, haben wir so einen Erfolgsfall
und müssen entsprechend reagieren, wenn der Test
fehlschlägt. Und dann sollten wir den
natürlich nicht fehlschlagen lassen, sobald irgendwie nur ein
Fehler auftritt, sondern ich muss mir realistische Grenzwerte
setzen, das heißt, ich kann zum Beispiel sagen, irgendwie, dass
95% der Requests bei so und so vielen Millisekunden.
Response Zeit abgehandelt werden oder ich habe eine bestimmte
Fehlerrate unter zum Beispiel 0,5% und dann muss ich mich
entscheiden, wie viele meiner Kriterien müssen fehlschlagen,
damit der gesamte Test fehlschlägt, damit ich natürlich
auch rechtzeitig abbreche und hier nicht unnötig Ressourcen
verschwende und im richtigen Zeitpunkt dann auch schauen
kann. Woran hat es gelegen um dann
auch nachzubessern? Woran hattet ihr lehren?
Ja genau, also wirklich, kann ich mal sagen, so.
Also wir haben so die Werte, die wir genommen haben, ist so, wir
haben also diese was du gesagt hast, diese Fehlerrate von 0,5%,
die haben wir uns auch so gesagt, wir möchten eigentlich
dass von, dass ich das einer aus 200 Requestern natürlich
irgendwie auch mal fehlschlagen darf, wir.
Wir haben gesagt, dass wir 95% aller Requests immer unter 300
Millisekunden abgearbeitet haben wollen.
Das ist auch so ein bisschen so, gerade so im Web, so eine
magische Grenze ab, wo sich das noch smooth für so einen
Menschen anfühlt, so ungefähr so einer Drittelsekunde, dann muss
die Antwort da sein, ganz wichtig, da wird natürlich jetzt
nicht mit Reinberechnet wie lange noch, meine Frontend
Technologie braucht um da irgendwas zu rendern oder sowas,
das ist rein, da werden Netzwerkrequests abgesetzt bis
die Antwort da ist. Das haben wir uns 300 als 300
Millisekunden gesetzt. Ich will, dass die CPU Last von
meinen Systemen eigentlich konstant unter 75% ist.
Wenn sie höher ist, mal ganz kurz okay, aber eigentlich, wir
skalieren schon etwas früher hoch, das heißt meine Systeme
sollen eigentlich nie über 75% CPU Last gehen und bei so
Datenbank Queries haben wir uns gesagt, die sollen ja alle, ist
immer so ein großes Wort, aber deswegen ja auch hier 95% dieser
Datenbank queries. Sollen unter 100 Millisekunden
abgearbeitet werden, sodass ich 200 Millisekunden noch übrig
habe. Für den Netzwerk Layer und für
den Computer Layer. Und bei uns fehlt ein Test.
Wenn 2 von diesen Metriken gleichzeitig gerissen werden.
Also wenn ich sage. Keine Ahnung, ich habe diese 0,5
Fehlerrate vielleicht gehabt, da habe ich vielleicht 0,6 oder
sowas gehabt oder vielleicht sogar 1%, aber alles andere hat
irgendwie gepasst. Dann würde in unserem Fall der
Test auch noch auch noch erfolgreich sein.
Man muss sich aber natürlich auch Gedanken machen, dass wenn
ich eine Fehlerrate von 80% habe, aber alles andere
funktioniert, also dieser Fehler, dieser Fehler
ultraschnell zurückkommt, weil es vielleicht schon ganz, ganz
früh in meinem in meinem Stack auftritt, dann muss ich
natürlich trotzdem den den Test fehlschlagen lassen, das heißt,
wir haben für die jeweiligen Metriken max wert.
Der, wenn er alleine überschritten wird, schon den
Test fehlschlagen lässt und halt so Werte die noch im Ok Bereich
sind. Aber wenn da 2 gleichzeitig über
diesen ok Bereich hinausgehen, aber noch nicht den Max Wert
getroffen haben, dann betrachten wir den Test auch als
fehlgeschlagen. Aber das ist vielleicht so ein
bisschen mal so diverse die wir da genommen haben, wir halten
die für Recht realistisch, ihr könnt aber auch gerne noch mal
irgendwie wenn ihr sagt Ey cool, dann übernehmen wir die auch mal
oder ihr könnt sagen das ist ja kompletter Quatsch, da haben wir
eine viel bessere Idee. Lasst uns das gerne auch solltet
ihr schon low Tests machen, auch gerne mal irgendwie in den
Kommentaren oder so wissen, was ihr da für für für Werte nehmt,
weil das ist so ein bisschen so der Heilige Gral.
Was sind da die Werte die ich haben will?
Wie gesagt, Wir haben gesagt unter 300 Millisekunden wollen
wir 95% aller Requests beantworten können und intern
nicht mehr als 75% CPU Last haben und nicht mehr als 0,5%
Fehler und Datenbank Queries unter 100 Millisekunden
abarbeiten können. Und die Sachen, die wir gerade
durchgesprochen haben, sowohl die verschiedenen.
Parameter wie virtuelle User als auch die entsprechenden
Metriken, die ich Messe, die konfiguriere ich natürlich in
einem Load Testing Tool. Da gibt es diverse Möglichkeiten
und Tools die ich dann nutzen kann.
Zum einen auf dem Open Source Markt, es gibt ganz viele
Lösungen die ich nutzen kann, Beispiele ganz populär Jay Meter
von der Apache Foundation, Wir haben gadling, Wir haben Locals,
wir haben k 6 mit. Diversen Vor und Nachteilen, so
wie ich es aus der aus der Praxis und vielen Gesprächen
kenne, ist JM tatsächlich so ein bisschen die Standard O 2
Lösung, wenn man das ganze auch Open Source Technologiebasierend
selber aufsetzt, unterstützt auch diverse Protokolle http web
sockets rest. Also was man alles so braucht um
klassische Webanwendungen. Testen zu können.
Es gibt aber, je nachdem welche speziellen Anforderungen man
hat, natürlich dort auch andere Möglichkeiten.
Aber wie gesagt, das so die Lösung die man am häufigsten
sieht. Jamieter ist, wie der Name ja
schon sagt, sehr, sehr Java Lastig.
Deswegen haben wir uns für Locus entschieden.
Das ist so ein Python basiertes Tool was das ist glaube ich
nicht ganz so mächtig wie Jamieter, aber auch ein bisschen
leicht, viel wichtiger zu schreiben, gerade weil wir auch
irgendwie Leute im Team hatten, die sich damit wohlgefühlt
haben. Ich glaube k 6, wie du gerade
gesagt hast, ist von Graphana, das heißt, es hat eine sehr
coole Integration schon direkt in deren Dashboards und freut
sich gerade noch starker Popularität.
Aber weil wir nirgendwo sonst im Stack Java hatten, haben wir da
jetzt von Jamie hinter die Finger von gelassen, aber es ist
glaube ich auch glaube ich sagen auf jeden Fall das populärste,
so ein bisschen so der Veteran unter den Low Testing Tools, der
eigentlich auch so ein bisschen alles kann.
Und diese Open Source Tools, die muss ich dann natürlich auf
meine eigene Infrastruktur aufsetzen.
Das heißt, ich brauche irgendwelche.
Virtuellen Maschinen, die irgendwo laufen, am besten
verteilt. Wo ich das ganze dann aufsetze
und da muss ich natürlich auch die Kommunikation zwischen
meinen einzelnen Low Testing Agents etablieren und die Daten
sammeln. Das hat natürlich eine gewisse
technische Komplexität, das heißt, da muss ich mich erstmal
ein bisschen reinarbeiten, muss die entsprechende Infrastruktur
aufsetzen und wenn ich das. Nicht möchte, gibt es natürlich
auch Software Service Lösungen die ich da nutzen kann.
Die gibt es von diversen kleineren Firmen oder auch
natürlich den großen Hyperscalern.
Das heißt, egal ob ich jetzt irgendwie auf WS oder Asher oder
Google unterwegs bin, finde ich dort eingebaute Low Testing
Lösungen, die sich natürlich optimal in die.
Eigenen Plattform Services integrieren und wo ich dann ein
super integriertes Monitoring habe, der Services aus der Cloud
Plattform selber, wo ich aber auch klassisch Anwendungen
testen kann, die jetzt nicht in dieser Infrastruktur gehostet
werden, wo ich dann einfach die Vorteile eines Saar Services
habe, wo ich nicht eigene Infrastruktur aufsetzen muss,
die Konfiguration gegebenenfalls.
Leichter ist also, da habe ich wirklich eine sehr breite
Auswahl. Ich muss auch nicht zu einem der
großen Anbieter geben, da gibt es auch andere kleinere Anbieter
mit Liste mal erstellt, wir können ein paar Links unten auch
in die Show Notes für euch packen.
Genau. Wir haben uns jetzt ist ja
wahrscheinlich keine Überraschung für die, die den
Podcast hier schon länger hören, wir haben das Projekt of Azure
aufgesetzt und da gibt es eben Azure App Testing, ich glaube
das hieß früher Azure Load Testing, kann jetzt auch noch
irgendwie so Frontend sein, deswegen haben die das umbenannt
und. Da ist natürlich einer der
großen Vorteile, also A in dem Fall werden jetzt auch irgendwie
glaube ich Apache JM und Locus als Technologien unterstützt.
Ich habe ja vorhin gesagt, wir haben das Skript in in der locus
Python Sprache geschrieben, wir konnten das dann einfach
hochladen und der zweite große Vorteil ist einfach, dass ich
einfach sagen kann, ey, wenn ich einen Test ausführe aus dem
System. Dann schalten wir für diesen
Test eine ddos Protection ab. Da kann ich sagen, das ist jetzt
keine ddos Attacke, sondern das ist ein low Test den ich mache
und das musst du sonst, wenn du halt irgendwie normalerweise so
eine ddos Attacken Erkennung oder so einen Schutz dazu
gebucht hast, natürlich dann auch extra für diesen Test
sagen, sonst sieht das natürlich sehr sehr schnell aus, wenn da
sehr sehr viele Requests von 3 bis 4 oder vielleicht auch 100
ähnlichen virtuellen Maschinen kommen.
Und der zweite Vorteil ist natürlich, dass ich da einfach
anklicken konnte. Was hatten wir sonst noch für
Services in der Azure Cloud, die Teil von diesem Load Test sind?
Da wurden mir direkt die Grafiken und die die Metriken
und die die ganzen Logs und so was und wird direkt da mit rein
gestreamt, das war natürlich sehr angenehm, wer auf Adobe US
ist, da gibt es distributed Load Testing, heißt der heißt der
Service da der läuft auch über mehrere Regionen ist Serverlist
und Google hat auch das Google Cloud Load Testing.
Stark, stark, koboniert ist basiert, kann ich auch noch mal
ganz speziell Container und sowas testen.
Also es gibt eigentlich in jedem Hyperscaler sowas, aber malte
hat ja gerade gesagt, es gibt auch noch ganz ganz ganz viele
andere Tools da draußen, ich glaube da kann man noch mal, da
kann sich ja jeder irgendwie noch mal selber einlesen, was es
da nicht alles gibt. Dann würde mich am Ende
interessieren, wie sind so ein bisschen so auch eure
Erfahrungen, wo sind so die Punkte, wo du gesagt hast, hey,
damit hatte ich nicht gerechnet, insbesondere im Hinblick auf das
ganze Thema Skalierung. Ich glaube, du hattest gerade
gesagt, dass die Anwendung, mit der du zu tun hast, auf
Cobanitis läuft und da auch eine gewisse Autoskalierung dahinter
liegt. Was sind so deine Erfahrungen
und vielleicht auch Überraschungen, als du jetzt zum
ersten Mal so einen low Test ausgeführt hast?
Überraschend ist natürlich immer, dass so eine
Infrastruktur gar nicht, also oft gar nicht so schnell
skaliert, wie man das sich eigentlich vorgestellt hat.
Also gerade im cobanitis Fall, irgendwann ist mein Cluster voll
und dann muss ich eine neue virtuelle Maschine dazu buchen.
Ich sag mal, wenn der Cloud Provider schnell ist, dann
schafft er das in einer oder 2 Minuten.
Mir da so eine WM hinzustellen. Das ist natürlich viel Zeit in
so einem Low Test. Das heißt ich muss deutlich
früher schon anfangen hochzuscrellen als wir das
gedacht haben. Das andere ist, dass so eine
Last verteilt, dass dann auch manchmal ungleich verteilt ist.
Das heißt, es kommt natürlich erst irgendwo, vielleicht auf
meiner Q oder in meinem API Gateway kommt diese Last an und.
Und da könnte ich ja eigentlich schon mal anfangen, wenn ich da
erhöhte Laster erkenne. Meine Datenbank zum Beispiel
Hochzuskalieren oder meinen Cluster hochzuskalieren.
Also je früher ich irgendwie Traffic erkennen kann auf seinem
Weg, da kann ich mir manchmal wichtige Sekunden sparen und
dass sie natürlich nicht alle gleich schnell und gleich
skalieren, gerade wenn es sich um irgendwelche SARS oder Pars
Systeme in der Cloud handelt, dann haben die vielleicht auch
unterschiedliche Skalierungsmechanismen
implementiert und wenn das nicht einfach alles.
Vms sind die ich selber kontrolliere, dann skalieren die
vielleicht einfach ganz unterschiedlich oder
unterschiedlich schnell oder unterschiedlich stark oder in
unterschiedliche große Pakete oder Kosten dann auf einmal
deutlich viel mehr und sowas also gerade in so einem
verteilten System hängt natürlich ganz ganz viel, da
irgendwie noch noch hinten dran, was einem dann ja eigentlich
erst so gewahr wird, deswegen ist so ein low Test eigentlich
so so mächtig, weil es einem das Halt zeigt.
Eine zweite Sache, die wir gemerkt haben, wo wir relativ
schnell dann irgendwie hinkamen, ist ja Moment mal.
Unser System kann jetzt aber halt von 10 Usern gleichzeitig
1000000 Requests entgegennehmen, aber wollen wir das überhaupt?
Sind das also wir müssen uns ja eigentlich Gedanken machen.
Wie? Ja, was ist denn so unsere
Strategie? Wie viele Requests erlauben wir
denn überhaupt pro User oder pro Crawler, bevor wir irgendwie
sagen, ey, da ist ja jetzt irgendwas nicht mehr in dem
normalen Nutzerverhalten, du hast eben so e Commerce erwähnt,
wenn ich jetzt irgendwie einen Shop habe, wo ich sage, da habe
ich wahrscheinlich so einen Klick pro Sekunde, wenn ich mir
irgendwie so durch die waren scrolle, dann klicke ich, ich
werde aber nicht auf einmal 10000 Artikel in meinen
Warenkorb legen. Vor allem nicht in einer
Sekunde, oder? Ich werde da nicht irgendwie 500
mal als der gleiche User auf bestellen klicken oder sowas.
Das heißt die zweite Strategie, die ich mir eigentlich nach oder
schon vor der Skalierung irgendwie Gedanken machen muss
ist, wann blockiere ich denn auch eigentlich irgendwie
Traffic? Du hast ja eben schon mal
gesagt, vielleicht will ich bestimmte Crawler gar nicht
haben auf meiner Website, die blockiere ich dann ganz, aber
was ist denn vielleicht auch ein Nutzerverhalten, wo ich ja
trotteln muss und sage okay du darfst.
Also ein Nutzer mit der gleichen id oder jedenfalls jemand aus
der gleichen IP Adresse darf in einem gewissen Zeitraum diese
Aktion maximal x mal ausführen, bevor ich ihm sage, Hey beruhigt
dich mal wieder dein Verhalten hier scheint gerade nicht normal
zu sein. Ja, eigentlich gibt es da 2
verschiedene Kategorien, einmal das Raid Limiting, das heißt ich
habe User oder Boards, die auf meine Plattform zugreifen und
ich erlaube Ihnen nur so und so viel request hat es ja gerade
beschrieben. Da gibt es verschiedene
Strategien, wie man das implementieren kann.
Das wird jetzt nicht im Detail drauf eingehen und dann gibt es
natürlich natürlich die Möglichkeit, wann blocke ich
komplett ab. Das natürlich wird es gerade
gesagt, in Cloud Plattform habe ich meistens eine Build in
Didors Protection, aber in bestimmten Fällen muss ich das
auch einfach selber bauen, ich muss erkennen, wenn ich in den
Bereich komme, der jetzt nicht mehr.
Dem normalen Userverhalten entspricht.
Das kann ich natürlich auch simulieren, über so eine Last
Test Software und dann muss ich in meiner Anwendung darauf
reagieren und dann entsprechend request auch einfach abweisen,
damit meine Anwendung für die anderen User weiterhin verfügbar
bleibt. Das ist natürlich ganz wichtig
aus denen am Anfang. Genannten Gründen aber natürlich
auch, wenn ich eine Anwendung habe, die automatisch skaliert,
muss ich mir auch überlegen, wie weit skaliere ich und wann fange
ich halt an, bestimmte Mechanismen in Gang zu setzen,
die halt einfach wirklich auch bestimmte Last abblockt, damit
mir nicht die Kosten aus dem Ruder laufen, weil auch wenn ich
irgendwie jetzt die super skalierbare Infrastruktur habe,
weil ich zum Beispiel auf so einer Hyperskiller Cloud laufe,
dann möchte ich da jetzt nicht unendlich Geld nachschmeißen,
nur weil halt irgendwie. Gerade einen Crawler über meine
Seite läuft oder irgendwie eine potenzielle ddos Attacke läuft,
das ist natürlich schon schlimm genug für die User, die ich
bedienen möchte, aber wenn dann mir noch durch eine automatische
Skalierung dann die Kosten völlig aus dem Ruder laufen, ist
das natürlich der Worst Case. Ja genau, also dieses eine,
dieses Trade limiting, was sie da üblicherweise auf so einer
Netzwerk API Gateway Ebene und das andere sind eben die Limits,
die ich mir selber setzen muss. Wieviel?
Server bin ich denn bereit, maximal überhaupt da
hinzustellen in diesen, in diesen Lastspitzen?
Und wenn ich dann was wegblocken muss, dann muss ich vielleicht
unterscheiden, vielleicht blocke ich erstmal allen Traffic, der
nicht menschlich ist. Oder ich kann bestimmte IP oder
irgendwelche PS oder manche Regionen und sowas dann noch mal
wegfiltern, aber das ist glaube ich noch mal eine Wissenschaft
für sich. Ein Thema, das wir noch gar
nicht angesprochen hatten. Wir haben jetzt ganz viel
darüber gesprochen, was Messe ich eigentlich?
Woher kommen eigentlich die Informationen?
Weil ein paar Dinge, die Messe ich innerhalb meiner Anwendung,
innerhalb meiner Infrastruktur und andere Dinge Messe ich ja
von der Clientseite wie habt ihr das implementiert, um diese
Informationen an einer Stelle zusammenzuführen?
Ja, wie wir das implementiert, ist ein großes Wort.
Wir haben, wie gesagt einfach den Azure App Tasting Service
benutzt, der Macht das schon für uns, aber das ist das wichtige
ist natürlich, dass man dann auf dieser observability Monitoring
Seite so die Korrelation erkennt zwischen.
Ja, was passiert denn, wenn wenn so ein Request geht, er über
ganz, ganz viele Ebenen, der kommt über das API Gateway rein,
geht übers Netzwerk, kommt dann in ein Backend, dann wird dann
wird dein Backend vielleicht irgendwie über deine Datenbank
oder mit anderen Services sprechen und das Ganze geht
wieder zurück und dann gleichzeitig zu sehen wie wie da
bestimmte bestimmte Werte bestimmte True pod Werte
gleichzeitig ansteigen, sich dafür irgendwelche coolen
Grafiken ausgeben zu lassen und das halt alles so übereinander
zu legen dann. Das hat schon irgendwie auch
Spaß gemacht das das Halt zu sehen, dass man wie ganz klar
sieht, ach guck mal, wir haben hier ein Problem, aber an der
Datenbank kann es nicht liegen, die langweilt sich eigentlich
gerade. Ja guck mal am API Gateway liegt
es aber auch nicht, das hat ja noch hier lange nicht seine
Limits erreicht, das dümpelt da irgendwie bei 20% CPU rum, ja
dann muss es das und das sein und so und das hat schon Spaß
gemacht da so ein bisschen dann irgendwie auf die Reise zu gehen
und dann das Ganze natürlich auch irgendwie diese.
Durch durch durch Tracing ja eigentlich so ein bisschen
dieses Bottle Neck zu identifizieren.
Was sind denn meine langsamen Endpunkte, was kriege ich denn
überhaupt zurück an an Fehlern, bei welchen genauen Endpunkten
und dann geht man so ein bisschen rein und guckt, woran
kann das denn liegen, kann also die Zeitfenster sich so ein
bisschen schieben, also man ist fast schon wieso ein ja wieso
ein Detektiv dann da unterwegs und kann sich die ganzen Sachen
angucken und kann das Dinge ausschließen, das hat schon
irgendwie Spaß gemacht dieses. Deswegen, ich glaube, dieses
Ergebnis lesen ist schon ein wichtiger Skill und natürlich
auch hilft Monitoring und so Observability nachher wieder zu
erkennen. Geht meine Last denn nachher
wieder auf ein normales Niveau runter, also so ein vorher
nachher vergleich? Wie war wieviel CPU und Memory
habe ich vorher verbraucht und jetzt dieser Lasttest vorbei,
ich bin vielleicht wieder auf der ganz normalen Last oder auf
0 Last ist irgendwas übrig geblieben?
Habe ich da irgendwelche Artefakte die da jetzt stehen?
Ist meine Datenbank jetzt doch? Doppelt so voll und wenn ich
diesen Test jetzt dreimal mache, ist die ganz voll und stürzt ab.
Und so. Also das muss ich natürlich auch
ein bisschen messen und im Auge behalten, ob ich da irgendwelche
Artefakte habe, ob irgendwas immer voller wird, immer voll
läuft, wir hatten ganz am Anfang schon über Memory Leaks und
sowas gesprochen. Das heißt, eigentlich muss ich
so Tests immer immer wieder machen, um zu gucken, ob sich
die auch irgendwie verändern. Im Rahmen meiner, also im Laufe
meiner Entwicklung. Wir hatten vorhin auch gesagt,
nachdem ich das jetzt irgendwie alles aufgesetzt habe und das
alles funktioniert, soll ich das natürlich regelmäßig machen, im
Idealfall irgendwo im Rahmen meiner normalen Development
Pipeline im Cicd. Wo ich dann so einen Last Test
durchführe? Ich mache das vielleicht nicht
bei jedem Pull request, bei jedem Verge von irgendwelchen
Änderungen, aber vielleicht immer wenn ich bestimmte
Releases habe, dann gehe ich auf eine preport Umgebung in eine
staging Umgebung, die in. Der entsprechenden Skalierung
meiner Produktionsumgebung entspricht und mache dann einen
Last Test darauf. Gerade wenn ich signifikante
Änderungen in meiner Anwendung gemacht habe, die vielleicht
Auswirkungen auf das ganze Anwendungsverhalten unter Last
habe, dann sollte das ganze vollautomatisch durchlaufen,
wenn ich das nicht erreichen kann, kann ich natürlich auch
regelmäßig manuell so einen Last Test starten, dann diese
Informationen rausziehen, aber noch besser ist es natürlich,
dass wenn ich eine. Ein neues Release plane das
Ganze dann automatisch getestet wird und nicht nur funktional
getestet wird, sondern auch unter Last getestet wird und ich
dann direkt auch die Rückmeldung bekomme, wenn es die
Qualitätskriterien, die wir vor ein paar Minuten besprochen
haben, nicht erfüllt, damit ich dann wirklich bevor ich das
Ganze in Produktion gebe, diese Probleme auch beseitigen kann.
Genau, wir testen komplett im QA.
Wir haben die Philosophie, dass unsere Quality Assurance
Umgebung. Genauso aufgebaut ist wie Prot.
Die ist natürlich nicht ganz so teuer wie prot, weil da generell
weniger Last drauf ist. Aber bevor bei uns irgendwas in
Produktion geht, jetzt einmal in QA, da wird dann ein last Test
gemacht. Wir machen halt jedes Mal wenn
wir über QA in Protolysen sondern Smoke Test, das heißt
wir machen mal eben kurz einen Last Test über so ein paar
Minuten lang gucken ob sich das noch alles so verhält, wie wir
das erwarten und machen aber auch wie du gesagt hast in
regelmäßigen Abständen die großen Last Tests.
Halt über längere Zeit, aber alles in der QA Umgebung.
Das ist halt vor allem deswegen wichtig, dass wir, damit wir
eben prot. Nicht überlasten, dass also das
nicht in der Produktivumgebung, wo wir schon diesen hohen
Traffic haben, dann noch der Lasttest oben drauf kommt und
wenn der dann nicht funktioniert, sondern dann reißt
er ja alles mit runter, auch die User, die ganz normal auf der
Plattform sind, deswegen machen wir diese Lasttests nie in
Produktion, sondern immer nur auf unserer gleichwertigen QA
Umgebung, die muss man sich natürlich leisten können, gerade
wenn sie gleichwertig ist. Aber so haben wir eben das auch
in unsere Cicd mit Eingebacken. Wenn wir Releasen, wird erst auf
QA release, da werden dann alle möglichen Quality Tests gemacht
und einer dieser Qualitätskriterien ist eben,
dass die Anwendung unter Last weiterhin so funktioniert, wie
wir uns das vorstellen. Und gerade wenn du die
Möglichkeit hast, weil du irgendwie auf einer Cloud
Plattform unterwegs bist, kannst du natürlich diese QA Umgebung
relativ klein halten. Im Normalfall aber wenn du den
Last Test ausführst, skalierst du die.
Hochskalierbereiche. Im gleichen Maße wie bei der
Produktionsumgebung kannst. Einen wichtigen Aspekt, den ich
noch kurz einwerfen wollte, ist halt, wie verhalten sich Third
Party Services hier bei diesen Lasttests.
Weil heute haben wir häufig irgendwelche externen AP is die
wir nutzen in unserer Anwendung, das muss ich natürlich auch noch
berücksichtigen, dass die natürlich auch entsprechend
diese Last unserer Lasttests abdecken müssen.
Ich muss halt auch schauen, dass wenn wir da Kosten entstehen
durch diese Zugriffe, dass nicht durch meine Lasttests plötzlich.
Unerwartet hohe Kosten für diese Third Party Services auch
entstehen oder ich vielleicht sogar durch unnormales
Nutzungsverhalten dieser AP is, was auch immer dort Probleme
bekomme, dass ich dann irgendwie selber geblockt werde, das ist
natürlich auch ein Aspekt. Nicht immer habe ich alles unter
Kontrolle, sondern ich habe auch Komponenten, die außerhalb
meiner eigenen Einflusssphäre liegen und die werden natürlich
bei so einem Lasttest in der Regel mitgetestet, aber ich kann
natürlich. Natürlich diese auch gezielt
ausklammern, indem ich halt irgendwelche Mogs dort aufsetze,
wo ich dann nur meinen eigenen Anwendungscode teste.
Aber diese Third Party AP is entsprechend in diesen last Test
nur mocke. Wobei ich dann nicht so der
größte Fan davon bin das zu mocken, weil das ist ja dann
geht natürlich auch ein bisschen weiter weg von der echten
Realität. Bei uns war es aber zum Beispiel
so, bei uns war genau dieser eine Service, wo ich vorhin
erzählt habe, der länger dauert, der redet mit einem Third
Partyservice. Ja, und da kannst du dann auch
einfach manchmal nicht viel machen.
Ne, vielleicht kannst du gucken, ob du da auf einen höheren
pricing Tier kommst und dann da mehr Requests pro Sekunde
hinschießen kannst. Aber wenn das eben nicht geht
und wenn das eben dein Bottle neck ist, dann musst du dir halt
irgendwas überlegen, dann kannst du das eben nicht mit Geld
erschlagen. Das Problem.
Sondern wir haben zum Beispiel ein Cashing eingeführt.
Wir haben da jetzt einen Cash dazwischen, der, weil wir sehr,
sehr viele sehr, sehr ähnliche bis hinzu gleiche Requests zum
Beispiel hatten, die müssten wir dann in unserem Fall irgendwie
zwischen Cash, oder wir müssen uns was Cleveres überlegen auf
Code Ebene, wie wir vielleicht weniger Requests gegen diesen
Third Partyservice schießen, aber absolut realistisch, dass
das vielleicht am Ende rauskommt, du kannst ja alles
richtig gemacht haben, aber hast nicht damit gerechnet, dass die.
Keiner der Identity Provider, den du verwendest oder dein
Authentication System, was du verwendest oder was auch immer
da irgendwie Teil von deinem großen Eco System ist.
Dein Feature Flex Service, den du jedes Mal abfragst, ob der
User dieses Feature sehen darf und dir vielleicht irgendwann
sagt, Hey, sag mal spinnst du kannst mich hier nicht 10 mal
pro Sekunde pro User Fragen, ob der User dieses Feature sehen
darf, das kann durchaus sein, dass der irgendwas abblockt und
dann sehe ich vielleicht auch, dass ich irgendwas falsch
gemacht habe, dass ich dann ein Anti Pattern oder sowas für
diesen Surf Body Service genutzt habe und.
Und manchmal kann ich einfach nichts machen.
Da muss ich mir selber was überlegen und dann wie gesagt
Cashing ist da wahrscheinlich so der häufigste Schluss, zu dem
man kommt, das haben wir jetzt irgendwie gemacht, das heißt, er
dümpelt jetzt noch irgendwo so ein Reddit Cash rum und seitdem
haben wir auch wieder sehr viel bessere Ergebnisse, natürlich
mit dem Nachteil den so ein Cash auch mit sich bringt, dass
vielleicht wir nicht immer top aktuelle Werte aus dem Surfparty
Service rauskriegen, sondern die zumindest eine Zeit lang Cash
und wenn der Surfparty Service die ändert, dann wir das
vielleicht nicht sofort, sondern erst nach ein paar Minuten
mitbekommen, das war in unserem Fall jetzt okay aber.
Das sind natürlich so Sachen, wo man sich auch Gedanken zu machen
muss. Du hattest gerade schon gesagt,
Anti Patterns und häufige Fehler, die man machen kann.
Wir haben natürlich nicht nur aus eurer Erfahrung, sondern
auch ein bisschen im Internet recherchiert, was sind so Dinge,
die. Häufig falsch gemacht werden,
wenn man solche Lasttests aufsetzt.
Und ich meine, das Erste ist natürlich, dass man irgendwie
nicht realistisch testet, dass man zum Beispiel nur einen
Endpunkt regelmäßig abfragt oder vielleicht.
Einen slash lasttest so Ding Ding Ding.
Und das ist natürlich kein Lasttest, sondern es ist
irgendwie ein Verfügbarkeitstest.
Also da muss man genau schauen, was mache ich da eigentlich und.
Und natürlich muss ich in dem Lastest auch ein realistisches
Userverhalten simulieren und nicht einfach auf irgendwelche
Endpunkte drauf hämmern, die halt am Ende von einem realen
Nutzer ganz anders genutzt. Werden ja die vielleicht einfach
gecasht werden. Also bei uns gehören ja auch
super viele Requests, die bei uns schon im API GAP gecasht
werden, wenn es genau dieselben sind.
So und dann kannst du mich halt 300 mal fragen, ob die verfügbar
sind, wenn ich verfügbar bin. Das wird mein Backend oder meine
Datenbank gar nicht erst treffen.
Und es gibt halt ganz, ganz viele von diesen Sachen, die man
vermeiden sollte. Eine andere Sache ist, dass man
kein Rampup macht, wir haben uns erst mal gefragt, warum, warum
machen wir diese rampup Phase, dass wir so langsam mehr mehr
User drauf haben, ja weil das halt realistisch ist, weil du
sonst irgendwie falsche Schlüsse daraus ziehst, dass deine
Plattform vielleicht irgendwas nicht kann, wo auf einmal von
100 Usern auf 10000 usern du irgendwie hochskalierst.
Ja, kann ich ja sagen, wird sehr wahrscheinlich deine Skalierung
nicht hinterher kommen, ist aber auch sehr wahrscheinlich
unrealistisch und das gleiche ist das natürlich auch gerade
schon, dass du überhaupt erst mal definierst, was willst du
denn überhaupt erreichen? Also wenn du keine Fail
creatoria hast, dann sagst ja ja, wir haben jetzt diesen
Lasttest gemacht, hat jetzt funktioniert, also ich konnte
jetzt die Requests abschicken, aber was mache ich mit diesen
Daten, dass das natürlich Quatsch, also ich muss mir da
Anfang an Anfang an überlegen. Was will ich erreichen und dann
auch sagen, dann ist der Test erfolgreich und dann ist der
Test fehlgeschlagen. Und ich meine in dem
Zusammenhang, wir hatten vorhin darüber gesprochen, muss ich mir
natürlich auch überlegen, wie definiere ich diese einzelnen
Metriken und was man da auf keinen Fall machen sollte, sind
irgendwie Durchschnittswerte annehmen, sondern die Best
Practices sind da wirklich zu definieren, was sind die Werte
für 95% meiner User 99% meiner User, je nachdem wie man seine
Kriterien da angelegt hat und nicht jetzt zu sagen, ja im
Schnitt passt das schon mit der Response.
Zeit, aber es geht halt extrem weit auseinander und vielleicht
die Hälfte meiner User haben nicht tolerierbare
Antwortzeiten, daher auch ganz wichtig, wichtig, wie bereite
ich die Daten am Ende auf für meine Kriterien, ob der Test
fehlschlägt oder nicht und natürlich auch innerhalb meiner
Dashboards, was schaue ich mir dann an?
Du hast gerade gesagt, man kann dann so.
Investigativ da durchgehen, aber wenn die Informationen, die ich
mir da Anzeige irgendwo wertlos sind und nicht dem realistischen
Userverhalten entsprechen, ist das natürlich etwas, was ich
wenig nutzen kann. Genau.
Und dann, wenn ich Ergebnisse habe, will ich die natürlich
versionieren, damit ich die vergleichbar mache.
Also oft mache ich auch eine Last Test um vielleicht eine
Änderung in meinem System zu validieren, ob es jetzt immer
noch gut läuft oder ob ich vielleicht auch, vielleicht kann
ich auch weniger aggressiv skalieren um Kosten zu sparen
oder auf einen kleineren pricing Tier gehen.
Was hat das für eine Auswirkung auf meine Response Zeiten?
So und deswegen muss ich natürlich Ergebnisse
vergleichbar machen miteinander ja so ein bisschen der letzte
Tipp, das hatte ich ja vorhin schon mal gesagt, nicht einfach
gegen Produktion testen, zumindest nicht ohne Abstimmung,
sondern am besten irgendwie eine eigene Umgebung haben, in der
man testet und natürlich irgendwie auch irgendwann sich
Gedanken darüber machen, welchen Traffic will man eigentlich
haben, so wie Wait Limits und so was mit einführen.
Das sind, glaube ich, so die besten Tipps, die man jetzt mal
machen kann. Und ich glaube, damit und mit
den Ressourcen, die wir noch zusätzlich unten in den in den
Shownotes verlinken werden, kann man glaube ich erstmal starten
und ich kann nur sagen, uns hat das sehr viel Spaß gemacht,
diese Lasttests irgendwie einzuführen und es ist schon
sehr faszinierend zu sehen, wie die eigene Anbindung, der sich
da verhält und dann auch auf Fehlersuche zu gehen, das war
schon cool, und das ist auch irgendwie Teil der regelmäßigen
Crcd Pipeline zu haben. Ich bin sehr happy damit, dass
wir das gemacht haben und wie wir das gemacht haben und.
Ich glaube, ein cooles Projekt. Super und wir hoffen auch, dass
euch das weiter gebracht hat, dass wir das Thema heute
intensiv diskutiert haben. Ich glaube, es war eine relativ
lange Folge, aber durchaus super spannend, ich habe auch viel von
Dir gelernt aus deiner Praxiserfahrung und wenn auch
euch das ganze weiter gebracht hat, dann lasst uns gerne auch
für diese Folge oder allgemein für den Podcast eine positive
Bewertung da, das könnt ihr auf den üblichen Plattformen.
Apple Podcast, Spotify oder auch über Youtube machen.
Da freuen wir uns natürlich sehr.
Und wo wir uns natürlich auch sehr darüber freuen, ist, wenn
ihr genauso cool sein wollt wie Julia oder der Sebastian und uns
einen Kaffee dalassen wollt für den Podcast.
Da gibt es unter der Folge in der Beschreibung auch immer
einen Link zu bei mir Coffee, da könnt ihr uns einen Kaffee
ausgeben. Da freuen wir uns immer sehr.
Oder wenn ihr vielleicht zu eurem eigenen Kaffee die
passende Gebrandete Nerd Tasse haben wollt, schaut euch gerne
in unserem kleinen Shop vorbei. Links zu allem findet ihr wie
immer in der Beschreibung. Und ansonsten freuen wir uns,
wenn ihr auch nächste Woche wieder mit dabei seid.
Beim to do Developer Podcast. Wir machen immer abwechselnd
eine Folge, wo wir die aktuellen Developer News zusammentragen
und eine Themenfolge wie diese Woche und dementsprechend freuen
wir uns, wenn ihr uns treu bleibt, falls ihr noch nicht
abonniert habt, macht das am besten.
Genau jetzt. Damit ihr auch am nächsten
Montag die News Folge mitbekommt.
So, jetzt aber Schluss. Ist schon eine viel zu lange
Folge geworden. Wir wünschen euch eine gute
Woche bis zum nächsten Mal. Macht's gut, schreibt viel Code,
testet viel, vor allem Unterlasst und bis nächsten
Montag ciao. Bis dahin.