Vollidiotheratech, hauptsächlich bei Otto unterwegs. Geht um Lasttest und wir sind gespannt.
Ja, danke. Ich bin ja sozusagen in der glücklichen Situation,
ganz viele Zuhörer zu haben, dank Steve Sodas und in
der schlechten Situation jetzt an Steve Sodas gemessen zu werden und super Fotos,
die Aussage immer auf den Punkt bringen,
habe ich natürlich nicht sowas Schickes.
Was ich mitgebracht habe, ist so die gesammelten Erfahrungen,
was man so in Sachen Lasttests tun kann,
um Webanwendungen skalierbar hinzubekommen
Die sich so in den letzten zwei Jahren angesammelt haben in dem Otto-Kontext,
was Björn schon erwähnt hat, die Do's, die Don'ts.
Und was man da so Nettes lernen kann. Und dass das
heute mit ein Thema ist, hat mit damit zu tun,
dass wir in den letzten Performance-Meetups das ganze Thema auf dem Kleinen,
kommt es darauf an.
Und was passiert im Browser und die Anzahl der Requests
zu minimieren, hoch und runter gemacht haben.
Und ja, ich denke, man kann auch an einer
anderen Stelle noch was falsch machen.
Und da gucken wir doch jetzt mal auf die andere Seite
so auf Hardcore-Technik
So, auch ich möchte damit anfangen, das Ganze zu wissen,
zu motivieren, warum sollte man so was tun?
Ich habe einfach mal gegoogelt nach Seite bricht zusammen,
unter Last und ein paar aktuelle Beispiele rausgezogen.
Irgendwie ganz wahllos. Ich hatte mich eine halbe Stunde gebraucht,
da hatte ich sechs Beispiele zusammen,
habe ich einfach mal drei hier rausgenommen.
Also da seit Beginn der iPhone-Vorbestellung am Freitagmorgen ist die Mobilfunkseite
der Deutschen Telekom nur schwer zu erreichen.
Irgendwie waren die überrascht,
dass ein gutes Angebot für Traffic sorgt.
Das sind die gewohnt
Anderes Beispiel, da Wander, eins von den vielen aufstrebenden E-Commerce-Themen,
einfach mal aus deren Kunden-Blog-Liebe, Leute,
hier mal die Sicht einer frustrierten Kundin und dann wird gejammert,
wie schlecht es alles ist und dass es immer so lahm
ist und dann ganz zum Schluss gehe jetzt woanders shoppen.
So und mal noch so ein drittes Beispiel,
weil die Regierung kann es,
das sind natürlich auch diesen Punkt sehr gut vormachen,
Wie man es nicht tun sollte, Datenbrutal,
Portal der Bundesregierung starten täubrig.
Die haben ja das Open-Data-Initiative und haben das angekündigt und mit
Jahren Anlauf, Daten Deutschland live gestellt.
Und dann haben sie nicht mit den hohen Zugriffszahlen gerechnet,
sagt der Sprecher des Innenministeriums.
Immerhin bis zu 20.000 Seitenaufrufe pro Stunde. Also sechs pro Sekunde,
eine gigantische hohe Zahl und sie waren total überlastet dadurch.
Alle drei Beispiele haben eines oder zwei Sachen gemeinsam.
Das eine Die Probleme waren eigentlich vorhersehbar. Die Last war
gar nicht so groß, beziehungsweise es war absehbar,
dass da Last kommen wird. Also man hätte,
die wurden nicht wirklich davon überrascht oder hätten nicht überrascht werden dürfen davon.
Das ist das eine. Und das zweite Problem ist,
die haben sozusagen 99 Prozent der Kosten ausgegeben.
Die haben das nämlich alles entworfen, Design per Marketing angekündigt.
Die haben die Entwickler und, und, und.
Die haben das alles hochgezogen. Und der Effekt von dem Ganzen ist,
dass die, für die es gemacht ist,
frustriert sind, sagen, ihr Blödmänner,
zu euch gehe ich nicht mehr
So, das ist so der Punkt,
weshalb es sich einfach lohnt, eine Anwendung zu bauen,
die, wenn man Erfolg hat und dann Last kommt,
weil die Last kommt ja nur,
wenn man Erfolg hat, nicht zusammenbricht.
Weil deshalb so der Punkt vom eigenen Erfolg erschlagen.
Also das passiert einem ja öfters mal. Kann man sehen,
dass wenn Leute Dinge zu erfolgreich werden,
dass sie dann unter der Last dieses Erfolgs zusammenbrechen.
Das gilt es halt zu vermeiden. Dann gibt es jetzt
öfters so den Spruch, na diese Probleme sind doch alt,
die gehören dort der Vergangenheit an.
Das ist doch jetzt ganz easy. Ich habe ja
die Cloud und wenn irgendwas nicht schnell genug geht,
dann miete ich mir halt einfach schnell einen Server dazu,
Wo ist noch das Problem? Da brauche ich dann nicht mehr
vorab viel Geld zu investieren und testen und messen und untersuchen.
Wenn es knallt, rumpelt, dann irgendwo da bei Amazon sagen,
hier von dem Ding noch eins fertig, ist das Problem gelöst.
So, und Grundidee ist ja ganz einfach,
man setzt da so irgendwie Standardkomponenten ein,
das hat man irgendwo in seiner Lösung mit dem Firewall,
ein Lotbalencer, irgendwelche Webserver, irgendwelche Upserver, Datenbank,
Cash, dann noch irgendwas und ist so Standard,
so am Ensurium, was sich so bei so einem Internetanwendung zusammensammelt.
Und da sorgt man jetzt dafür,
dass man den tollen Lotbalencer hat und wenn die Dinger nicht reichen,
dann stelle ich halt da da eins daneben und wenn die
nicht reichen,
stelle ich da
auch eins daneben
Das Problem ist, in der Realität knallt es natürlich nicht dort,
wo ich einfach skalieren kann, sondern da, wo ich nicht einfach skalieren kann.
Ich habe mal alles rot eingefärbt, was in dieser Architektur nicht ohne weiteres skaliert,
weil es dann nämlich da jeweils nur ein Ding davon gibt. Nimm mal,
wenn es nur eins gibt,
dann ist das mit dem horizontalen Skalieren nicht mehr so einfach,
sondern kann ich noch gucken,
gibt es denn auch in dem Regal für die ganz teuren Lotbalenzer ein,
der noch mehr kann,
aber das ist eines der ganz typischen Button-Next,
wenn ich jetzt wirklich viel Last habe,
und ich verlasse mich auf den einen Point-Lotbalenzer,
der kann halt auch
nur endlich viel
Das zweite typische Problem, was ich nehme,
diesen Buttlenecks habe, ist,
dass ich zwar eine Architektur ausgewählt habe, die prinzipiell skaliert,
aber beim Implementieren und Benutzen dieser ganzen Lösung irgendwas nicht ganz
richtig bedenke und dann stellt sich am Ende raus,
theoretisch könnte das jetzt skalieren, das tut es einfach nicht.
Und das ganze Ziel von dem,
was wir mit Lastes machen, ist es,
diese Stellen mitzubekommen,
bevor der Kunde
deshalb frustriert ist
Darum geht es jetzt eigentlich in dem Vortrag,
mal zu gucken, was kann man denn dafür tun?
Sollte man dafür tun, dass man entspannt live stehen kann,
weil man sich sehr sicher ist,
sowas wie der Telekom passiert mir nicht.
Ja, und das fängt man damit an,
dass sich die Lastanforderungen überhaupt mal definieren muss.
Ich muss mir vorab Gedanken machen, mit welcher Last rechne ich denn?
Was will ich denn abkönnen? Was muss ich denn abkönnen
? Dann das Ganze funktioniert. Und die typischen Kennzahlen,
die es in diesem Bereich gibt,
ist immer ja,
wie viele Leute gehen da drauf
Wie viele Sessions Visits sind denn da parallel? Und wie
viele Klicks machen die denn dann auf die verschiedensten Seiten?
Das sind die typischen Metriken,
mit denen wir in unseren Webanwendungen zu tun haben,
wenn wir skizzieren oder beschreiben, was kommt da für eine Last an?
Wobei je nachdem,
mit wem ich da spreche und mit den Fachleuten oder mit den Technikern,
heißt das dann immer so ein bisschen unterschiedlich und bedeutet letztendlich auch ein bisschen was unterschiedliches.
Also die Fachleute, die sprechen über die Anzahl der Besucher und die Techniker,
da haben wir User in der Datenbank,
wie viele von den Dingern gibt es da in der Tabelle
Die sprechen hier von Visits pro Monat und die sprechen eher,
wie viele Sessions haben sie denn in der Stunde,
die sie händeln, weil sie genau wissen,
da mein Server macht eine Session auf und dann wird
ein Session-Objekt erzeugt und das muss ich dann irgendwo hindukliplizieren,
das kann eine bestimmte Größe haben und wie viel Hauptspeicher verbraucht das und sowas alles.
Und die sprechen hier von Pageviews und Impressions und die gucken eher so,
wie viele Hits haben denn meine Server zu verarbeiten,
wie viele Requests kommen da an, die bedienen müssen.
Und das hat zwar irgendwas miteinander zu tun,
diese beiden Sachen jeweils, aber es ist nicht identisch,
was das meint
Um da nur mal so die Beispiele zu machen.
Die Anzahl der Besucher sind eben alle, auch die,
die nicht angemeldet sind und wo es kein User-Objekt in der Datenbank gibt,
weil der ist einfach nur mal so raufgegangen, den gibt es als User noch nicht.
Hier bei der Sache, die Session hat vielleicht ein technisches Timeout,
damit sie nicht so viele Dinger vorgehalten werden,
wenn der eine halbe Stunde lang nichts tut,
dann kriegt er eine neue Session irgendwie im Hintergrund vielleicht, während aus Sicht
Ja, der Fachleute und auch des Benutzers,
der hat sich halt vormittags da angemeldet hat,
was angeschaut, dann hat er Mittagspause gehabt,
der kommt nach der Mittagspause wieder, der surft da weiter.
Das ist eigentlich immer noch eine Visit, obwohl es mehrere
Sessions sein können in dem System. Das ganze Thema Bot-Sessions,
das wird natürlich bei den Visits pro Monat,
die ich als Fach, als Business-Mensch plane und abkönnen will,
überhaupt nicht mit berücksichtigt, weil als als Business-Mensch-Bots, naja,
klar gibt es sich, aber interessieren mich doch nicht,
will ich ja Kunden bedienen mit meiner Anwendung.
Und genauso ist es hier mit den Pageviews,
auch dort ist der Betrachtungszeitraum
ganz anderer
Den Hits gehen, eben die ganzen statischen Ressourcen mit ein,
die E-Checks-Requests, die Trickling-Requests, die API-Calls und, und,
und, und, und. Das sind alles Hits,
ohne eine einzige weit Tropege-Impression oder ein Page-View im fachlichen Sinne
zu produzieren, sondern die sind alle damit verknüpft.
Und insofern sind die Zahlen, die ich von denen in der zweiten Spaltung,
von denen in der ersten bekomme, teilweise total unterschiedlich,
auch wenn eigentlich das Gleiche gemeint ist.
Und die Frage ist jetzt, wenn ich ein Lasttest plane,
wonach richte ich mich denn dann eigentlich,
was muss ich denn da als Basis nehmen und auf
welcher Ebene sollte ich meine Anforderung definieren
Und die Empfehlung, die ich nur machen kann,
ist, sich generell an diesen Business-Kennzahlen auszurichten,
weil das sind irgendwo die Ziele,
die gereicht werden müssen über die Business-Kennzahlen,
generiert sich dann auch irgendwie das Geschäftsmodell dieser Anwendung und damit auch das,
was es dann kosten darf, das zu erreichen.
Aber die Abweichung zu den technischen Anforderungen in die Betrachtung,
was ich jetzt für Last produzieren muss,
um diese Business-Kennzahlen nachzubilden, mit zu berücksichtigen,
weil letztendlich müssen meine Server die technische Last abkönnen.
Nicht nur die fachliche
So, und um das mal mit diesen Betrachtungszeitraum auch
zu illustrieren, ich habe einfach mal die Tageskurve genommen.
Und wenn jemand sagt,
also wir haben so und so viel Pitch Views am Tag,
dann spricht er über einen Durchschnittswert pro Zeiteinheit von dem hier.
Und wenn ich mir überlege, was muss ich in meinem Lastest nahestellen,
damit der realistisch ist, dann müssen wir das hier können.
Da reicht es nicht, das zu können,
weil dann würde ich ja am halben Tag immer brach liegen
und kaputt gehen,
wenn ich
nur den Durchschnittswert könnte
Also es ist ganz wichtig, wenn wir über Zielwerte sprechen,
dass man den richtigen Betrachtungszeitraum wählt,
und immer daran denkt, wenn wir Lastes machen,
uns interessieren immer nur die Peak-Anforderungen, wir werden die Business-Leute,
wenn die über ihre Kennzahlen und was sie im Business-Case erreichen wollen,
reden, dann sprechen die immer über Durchschnittswerte.
Ich habe das mal hier noch ein bisschen weitergetrieben,
wenn wir da nicht nur auf eine Tageskurve gucken,
sondern mal gucken,
was so im Laufe eines Monats in dem Auf und Ab des Traffics passiert,
dann im Businessplan würde dann irgendwie auftauchen,
ich muss 135 Page Impressions können,
pro Zeiteinheit,
und unser Lasttest muss eigentlich
435 darstellen können
Also das kann erheblich auseinanderlaufen. Einfach nur,
weil man den falschen Betrachtungszeitraum für seine Kennzahlen vielleicht nimmt.
Das Zweite war ja, diese statischen Ressourcen,
ich habe einfach mal die Amazon Homepage genommen.
Ein Page-View über 100 Requests. Steve hatte das ja auch
schon mit drin da, mit diesen ganzen Sachen, die da sind.
Muss man einfach, wenn man sein Lastmodell aufmacht,
mit berücksichtigen, weil der Server muss halt auch diesen
scheinbar trivial auszuliefernden statischen Content liefern können,
wie auch immer ich den ausliefere
Und wenn ich nur in meinem Lasttest daran denke, wie meine hochkomplexe,
fachliche Funktionalität in der entsprechenden Anzahl schnell genug durchgeführt werden kann und dann bei den scheinbar einfachen,
da gibt es noch ein bisschen statischen Content, die müssen wir auch ausliefern,
Patze, dann habe ich eben auch nur das Resultat, dass insgesamt die Seite langsam ist.
So, was man da machen kann und machen sollte,
jetzt auch bei Bezug auf Lasttest, in dem Moment,
wenn das auf dem Content Delivery Network ausgelagert wird,
diese ganzen statischen Content-Geschichten,
muss ich die natürlich auch in meinem Lasttest jetzt nicht mehr extra berücksichtigen,
weil ich will ja die Lösung, die ich baue,
testen, dass das Content Delivery Network Meine Last auch noch abkann,
das sollte ich bei der Auswahl des richtigen Content Delivery Networks einmal geprüft haben,
das muss ich nicht jedes Mal wieder neu prüfen.
Wenn es nicht auf dem CDN ausgelagert wird,
dann wenigstens irgendwie noch auf eine eigene Domain auslagern,
dann kann ich das auch einmal abtesten und muss es nicht in jedem Lasttest drin haben.
Aber wenn es keine Lösung gibt in meiner Anwendung,
die dafür sorgt,
dass der ganze statische Content von anderen Servern kommt,
als meine normalen Anwendungsrequesten,
dann muss ich diese ganzen Refests auch wirklich mit im Lasttest generieren,
um die Auswirkungen,
die das auf meine Applikationsserver hat,
mit zu berücksichtigen
So, woher kommen diese ganzen zusätzlichen Requestes? Sind diese ganzen statischen Sachen,
das ist alles mögliche Monitoring-Zeug, was ich mit berücksichtigen sollte?
Alles, was da Monitor hat, synthetische Monitors.
Und es ist alles zusätzliche Last,
die auch auf den Servern mit drauf ist und die dafür sorgt,
dass rein technisch gesehen viel mehr ankommt auf meinen Servern,
als das, was der Fachmann als Business Case mal gesehen hat.
Jo, nur mal so ein paar Erfahrungswerte,
also bei uns sind die Bots für 50 Prozent aller Sessions
zuständig und für 10 Prozent aller Requests,
die auf die Server eiden
Und das sind nur die Suchmaschinenboots. Kannst du,
kann ich dir fragen? Ja, also ich versuche,
wollte ich vorab sagen, ich versuche schnell durchzukommen und
ihr müsst mich dann an den Stellen bremsen und einhaken,
wo es interessant wird.
Dann glaube ich, jetzt nicht schnell erwischt, aber okay.
Kannst du die 50 Prozent runterbrechen,
was durch euer Monitoring passiert und was von Externen zu kommen?
Also unser Monitoring ist irgendwie 0,0 Prozent.
Von den 50 Prozent ist ungefähr 20 bis 25
Google Boot
Zehn bis zwölf aller Requests aller Sessions kommt von Bing und
dann der Rest ist weniger. Das hat damit zu tun,
dass in unserem alten Shop eine Session eben daran festgemacht wird,
dass beim ersten Mal ein Cookie vergeben wird und wenn der dann wiederkommt,
dann hat er den Cookie schon und dann wird er dieser Session wieder zugeordnet.
Bots akzeptieren keine Cookies und schicken die beim nächsten Mal auch nicht wieder mit.
Das heißt, da kommt jeder Request wieder als neue Session daher.
Das sind dann alles sogenannte One-Click-Sessions, die machen genau einen Aufruf,
da wird ein Session-Objekt automatisch dann erzeugt in dem alten Shop.
Der ganze Aufwand, diese Sessions zu produzieren,
findet statt
Vollkommen umsonst, weil da wird Nins weiter die Quest kommen.
Ist aber wichtig, das zu wissen,
weil wenn dieses ganze Session-Handling tatsächlich in der eigenen Lösung passiert und nennenswert Ressourcen verbraucht,
dann ist es wichtig, dass mit im Lastes zu simulieren,
weil das eben kostet.
Bei uns heißt bei Opto.de. Otto.de alt, ja.
Also das ganze Lasttesten bezieht sich eher darauf, dass wir
die neue Lösung, die da am Werden ist, bauen.
Da ist das mit den Sessionen ein bisschen besser gehandhabt worden,
aber trotzdem muss man sowas einfach mit auf dem Schirm haben,
wenn man einen realistischen Astist baut
Damit man nicht davon überrascht wird,
dass man doch alles getestet hat und trotzdem funktioniert es nicht.
So, das Ganze führt dann dazu, dass man irgendwie zu Last-Anforderungen kommt.
Wir haben jetzt sozusagen hier verschiedene Meilensteine, das sind die Spalten.
Und dann gibt es verschiedene Rubriken, wie viele User wollen wir abkönnen,
wie viele Visits, Spots pro Stunden, Sessions,
Pageviews und, und, und, und. Wie viele AJX-Requests,
und dann gibt es jetzt für jeden Meilenstein Ziele,
was wir da können wollen,
weil Rom wird nicht an einem Tag erbaut,
Performance und Last kriege ich nicht dadurch hin,
dass ich am Ende eines ein- oder zweijährigen langen Entwicklungszykluses
mal eben noch schnell eine Woche Last-Tests mache
Sondern dem muss man sich eben auch annähern.
Und das ist einfach nur die Botschaft hier,
auch für solche Ziele abgestufte Meilensteine festlegen und sich schrittweise dem annähern,
was man erreichen will.
So, wo kommen solche Kennzahlen her? In unserem Fall
war es jetzt trivial. Wir haben ein Altsystem, was abzulösen ist,
dadurch, dass ich so einen Shop neu technisch baue,
habe ich nicht einen Kunden mehr und nicht einen Pitch für mehr.
Wahrscheinlich ist die Last erstmal die gleiche wie im Alten.
Da kann ich also aus dem Tracking wunderbar abschreiben und weiß genau,
wie viele Artikel-Detailseiten da pro Stunde aufgerufen werden und wie oft
da Leute auf die Dorfront gehen und wie viele Sessions sind
und so
Für Projekte, die bestehende Webangebote neu bauen, ist die beste,
beste, beste Quelle für Lastanforderungen, das Tracken des bisherigen.
Und wir haben jetzt genaue Übersicht, welche Art von Seiten
wären da wie häufig aufgerufen, bauen das entsprechend nach.
Für die, die sagen, ja,
ich baue was Neues, das gibt es heute noch nicht.
Das ist die zweitbeste Quelle für Mengenanforderungen,
die Business-Case-Rechnung für das neue Angebot
Wenn ich weiß, ich baue hier eine neue, super Seite,
das ist ein Informationsportal und soll sich über Werbung refinanzieren.
Und ich habe ein Business-Case gerechnet,
ich will da irgendwie 10 Millionen Umsatz mit den eingeblendeten Werbebannern
auf dieser Infoseite machen und ich kriege pro Werbebanner laut Business-Case Rechnung 50 Cent,
dann weiß ich, wie viele Hits ich haben muss auf meinem Infoportal,
um auf meine 10 Millionen kommen zu können.
Und dann habe ich schon mal,
was die Anzahl der Page Views betrifft, eine Vorgabe,
das muss meine Lösung ja mindestens abkönnen,
sonst kann ich meinen Business-Case nie,
nie,
nie erreichen
So, insofern ist so eine Business-Case-Rechnung für alles, was neu gebaut wird,
eine sehr gute Quelle, um zu grundlegenden Mengen Annahmen zu kommen.
Die muss man dann natürlich entsprechend aufrunden und Sicherheitsmargen reintun und dergleichen mehr,
um da auf der sicheren Seite zu sein.
Aber da heute ja kaum noch irgendeine nennenswerte Investition getätigt wird,
also Geld ausgegeben wird, um Anwendung zu bauen,
ohne zu wissen, was rauskommen soll,
müsste es eigentlich immer irgendeine Business-Case-Rechnung, eine Wirtschaftlichkeitsrechnung,
eine begleitende Rechnung zu einem Investitionsantrag oder,
oder,
oder was geben
Wo die Leute, die gesagt haben, wir sollten das Bauen sagen, warum.
Und da muss man irgendwas ableiten können. Also Anmerkungen?
Ja. Gerne. Als Anbieter von Lasttests, Lösungen.
Würde ich hier noch sagen, es gibt es.
Ich würde den einen Lasttests oder den verschiedenen verschiedenen Formen
gemacht haben. Und was hier noch geht,
aus meiner Sicht ist eigentlich die Ziele der verschiedenen Abteilungen,
die mit der Internetseite zu tun haben.
Also zum Beispiel in der IT würde man sagen,
ich mache Gasttests, bevor wir das crashtesting zu sehen,
oder in welchen Punkten sind wir zuerst zusammen
Ja. Wer sagt, naja, mein Fluss ist das Weihnachtsgeschäft,
also ich brauche vom Peak und der muss mal so 24 Stunden gefahren werden.
Also ich stimme dir vollkommen zu,
wenn meiner Betrachtungsweise ist das aber zwei Paar Schuhe jetzt,
weil ich spreche ja nicht darüber,
wie die Anforderungen an den Lasttest sind,
sondern ich spreche erstmal über die Anforderungen, die meine Lösung können muss.
Und im nächsten Schritt überlege ich mir dann,
was für Last es muss ich jetzt machen,
um meine Lösung daraufhin zu überprüfen,
ob die das gut genug kann
Und ja, dann kommen solche Überlegungen rein,
dass ich mal einen Stresstest mache und wie weit komme ich denn und und und.
Kommen wir auch gleich nochmal drauf. Aber da geht es erstmal nur erstmal,
welche Lastanforderungen muss mein System, was sich hier bauen,
untersuchen will, überhaupt abkönnen, um den wirtschaftlichen Business nutzen,
den ich davon haben will, erbringen zu können.
So, das Nächste ist, jetzt muss ich überlegen,
wenn ich Lastanforderungen habe, wie kann ich sie überprüfen,
welche Art von Last, das brauche ich dafür.
Da gibt es jetzt auch wieder ganz, ganz viele,
das ist auch kein vollständiges Bild, ist nur mal so skizziert,
also ich unterscheide in meiner Begrifflichkeit,
die ist leider nicht standardisiert und nicht ganz einheitlich zwischen Performance-Messung,
die eigentlich immer bedeuten, ich messe, wie schnell,
wenn ich ein Request reinstecke, kommt die Antwort zurück.
Also wie schnell ist der Rauntrip? Wie schnell ist die
Antwort ohne mir über Lastgedanken zu machen? All das,
was wir, wenn wir klein seid, die Messung machen,
egal ob es jetzt Real-User-Monitoring oder auch synthetische Tests sind,
da machen wir lauter einzelne Performance-Messungen.
Vielleicht im Real-User-Monitoring ganz, ganz viele davon. Aber das Ziel ist,
rauszukriegen, ein Request, wie schnell wird der beantwortet, fertig.
So, ein Lasttest ist, wie verhält sich so ein System unter Last?
Da muss ich irgendwie die Last draufgeben, die Lastanforderungen,
die wir diskutiert haben, ist dann die Basis,
die Messlatte,
wie viel Last sollte ich
da draufgeben
Aber ich versuche rauszuklingen, wie verhält sich das System,
wenn ich da diese Peak-Last anlege, mit der ich rechne.
Und Stresstest ist dann da eins draufgesattelt.
Ich setze das System bewusst und dann noch viel mehr Last,
um zu gucken, wenn ich es überfordere,
wie verhält es sich dann, wie schnell bricht es zusammen,
kommt es auch mit mehr Last als der,
die ich eigentlich haben will, klar.
Und was ist das Element, was als erstes zusammenbricht,
was also mein schwaches Lied in der Kette ist und solche Sachen.
Das gucke ich mir beim Stresstest an.
So, dann gibt es einen unterschiedlichen Umfang.
Ich kann Lasttests machen, um einzelne Komponenten in meinem System
zu testen
Ich habe irgendeinen spezialisierten Server, der meinen statischen Content ausliefert.
Dann mache ich einen Lasttest, wo ich nur gucke,
kann der diesen statischen Content ausliefern bei einem Komponentenlasttest.
Das System Lasttest ist, ich habe das Gesamtsystem aus all
seinen Einzelkomponenten bestehend und setze das gesamthaft unterlasst und gucke,
ob dieser Gesamtverbund das leistet, was er leisten soll.
Und ich habe auch noch eine unterschiedliche oder eine Unterscheidung in Bezug auf eine Zielsetzung.
Was soll mir denn der Lasttest eigentlich als Ergebnis liefern?
Und da unterscheide ich prinzipiell zwischen Entwicklungsseitchenlasttests, Genauso wie die Entwicklungsseitien,
Unit-Tests und, und, und, und, und,
die es da auf funktionaler Ebene gibt,
sozusagen dem Entwickler helfen, sich davon zu überzeugen,
dass die Lösung, die er gebaut hat,
sich so verhält, wie er das haben will.
Oder die ihm sagen, warum es sich noch nicht so fällt.
Da geht es darum, Fehler zu finden,
wirkt Mechanismen zu überprüfen, Annahmen zu verifizieren,
haut das hin, klappt das tatsächlich so,
kann mein Konstrukt das jetzt so abhandeln, wie ich mir das dachte?
Versus Abnahmelasttests, wo es nicht mehr darum geht,
Whitebox-mäßig zu sagen, ich weiß ja genau,
wie mein System funktioniert und einen Teil daraus will ich jetzt mal untersuchen,
ob der so funktioniert,
wie gedacht
Sondern ich mache eine Blackbox, ich habe meine Anforderungen,
ich gucke, kann das System diese Anforderungen erfüllen.
Wenn ja, kann ich es abnehmen, kann ich sagen,
kann so live gehen, wenn nein, dann heißt es Zurückentwickler,
du hast mir nicht das geliefert, was du liefern solltest.
Das ist deshalb jetzt ganz was anderes,
weil wenn ich hier so auf dieser Seite teste,
dann will ich irgendwas herausfinden können,
dann versuche ich gezielt Zustände in meinem System hervorzurufen,
wo was Besonderes eintritt, um was drüber zu lernen über mein System.
Während hier versuche ich möglichst genau das nachzustellen,
was es jetzt leisten soll,
wenn es das kann,
ist gut
So, genauso wie es bei den funktionalen Tests eben einen Unterschied gibt zwischen
den Tests, die die Entwickler bauen und irgendeinem User-Acceptance-Test,
die irgendeine abnehmende Organisation durchführt.
So, und das, was ich heute erzähle,
das sind eher so die Sachen, die ich jetzt da markiert habe.
Wenn ich jetzt dann Last-Tests mache,
dann ist in der Regel ganz wichtige Last-Skalierbarkeitsanforderungen einmal ein System,
dass das möglichst linear skalieren soll.
Und linear skalieren heißt, je mehr User da draufgehen und
irgendwie Anfragen machen, desto mehr Durchsatz kriege ich durch mein
System durch
Das ist also dann hier so eine schöne lineare Kurve,
deshalb auch lineare Skalierbarkeit. Und das kann ich dann erreichen,
wenn die Antwortzeit auf jeden einzelnen Request die ganze Zeit konstant bleibt,
egal wie viele Anfragen auch immer kommen, die Antwort ist immer gleich schnell.
Das ist lineare Skalierbarkeit. So,
diese ganze lineare Skalierbarkeit ist deshalb wichtig,
weil vielleicht kann ich ja nicht immer 100 Prozent meiner Last nachstellen,
weil das kostet ja eine ganze Menge Geld,
Testsysteme zu haben, die so leistungsfähig sind, Lastgeneratoren,
die so viel Last produzieren können und, und, und.
Wenn ich dann aber sage, okay,
dann stelle ich halt nur 10 Prozent oder 1 Prozent nach,
dann brauche ich ja irgendeine Variante,
wie ich dann von meinen verkleinerten Ergebnissen hochrechnen kann,
auf das, was ich wohl im Gesamtsystem ergibt.
Und die einfachste Art von Hochrechnung ist limeare Extrapolation.
Ich multipliziere einfach mit dem Faktor und hoffe, dass es gut geht.
Und das klappt halt nur, wenn es linear skaliert.
Deshalb sollte man in seinen Lastests auch rauskriegen,
ob man linear skaliert, weil an den Punkten,
wo man anfängt, nicht mehr linear zu skalieren,
passieren interessante Dinge im System und man stößt auf die Engpässe,
die einem wahrscheinlich wehtun werden.
So, ich habe jetzt deshalb,
oder wir haben so ein Standardvorgehen,
wir machen bei unseren Lastests immer auch Lastest,
die mit
linear steigender Lastgenerierung arbeiten
Das heißt, wir testen dann eine Stunde und wir fangen irgendwie bei null an
und enden irgendwo und machen jede Minute ein bisschen mehr Last.
Weil wenn ich solche Lasts mache, dann kann ich einfach mir mitprotokollieren,
wie viel Durchsatz habe ich denn geschafft und kann sofort erkennen,
hat denn das linear skaliert?
Wenn es linear skaliert hätte, dann hätte das irgendwie so
aussehen müssen, meine Kurve. Dass das nicht gemacht hat,
skaliert das System, was da gerade da gemessen wurden,
nicht linear und man kann relativ schnell ein paar wichtige Bereiche erkennen.
Man kennt nämlich den Bereich grün,
wo ist linear skaliert
Dann gibt es den Bereich Gelb, wo es nicht mehr linear skaliert,
arbeitet Durchsatz, steigt noch mit der Anzahl der Anfragen.
Also Durchsatz ist ja,
wie viele Anfragen habe ich erfolgreich beantworten können pro Zeiteinheit?
Dann gibt es den Bereich der Sättigung. Ich habe zwar mehr Anfrage,
aber die stellen sich einfach nur noch hinten an die Q an.
Je mehr Anfrage ich habe, desto langsamer wird die Antwortzeit,
die Anzahl der beantwortenden Anfragen pro Zeit wächst nicht mehr.
Und dann gibt es den roten Bereich,
da bin ich schon in der Überlastsituation drin,
obwohl noch mehr Leute anfragen, kommt immer weniger durchs System durch.
So, wenn ich ein System im roten Bereich habe,
dann Kann ich darauf warten, dann wird es auch irgendwann ausfallen.
Insofern muss ich wissen, wo der rote Bereich ist.
Schon in den orangenen Bereich sollte ich nicht reinkommen. Und interessant ist,
warum und wegen welcher Zusammenhänge ich im gelben Bereich lande.
Also wo ich dann dem Vater der linearen Skalierbarkeit verlasse.
Jo, dann Thema Last-Tes, meine Empfehlung, möglichst realistische Last das machen.
Heißt, ich kann zwar rein rechnerisch runterskalieren und hochrechnen,
aber eingedenktes Bild ist vorhin, wo wir gesehen haben,
da gab es Komponenten,
die skalieren recht gut
Ab welche, die skalieren nicht ohne weiteres.
Das mit dem Hoch- und Runterskalieren auf allen Komponenten sauber hinzukriegen,
ist eine Kunst, die beherrscht keiner. Das heißt,
immer, wenn ich in einem verkleinerten Maßstab teste,
leidet die Aussagekraft meines Lasttests.
Und da gibt es von irgendeinem Autovorstand so ein Bonbo,
der hat gesagt, okay,
der beste Prototyp wird im Maßstab 1 zu 1 gebaut
Also, einfach 100 Prozent Last. Das ist das Optimum,
was man an Aussagekraft kriegen kann. Ja, und dann heißt,
möglichst realistisch, ich muss diese ganzen zusätzlichen Requests mit Bröckschen richtigen,
ich muss den richtigen Mix dieser Requests machen.
Also nicht einfach sagen, ich mache mal jetzt,
ich weiß ja nicht, was da passiert,
ich mache mal 100 Aufrufe in der Homepage und 100 Aufrufe davon,
100 Aufrufe davon sind meine drei wichtigsten Seiten,
wird schon insgesamt dann irgendwie aufgehen.
Heißt, ich muss mal über sowas wie Session-Längen Gedanken machen,
also wie lange sind die Kickpfade,
die so ein Kunde durch einen Shop nimmt oder durch
ein Web-Angebot
Weil es gibt ja vielleicht Dinge, die im Laufe der Session immer auffälliger werden.
Zum Beispiel die Historie der besuchten Seiten darzustellen. Ich muss
auch an die Abfolge der Requests denken und die in der richtigen Reihenfolge machen.
Und gerade wenn man so jetzt an die verschiedensten E-Commerce-Angebote denkt,
ist ja das Problem, da gibt es keine vorgeschriebene Reihenfolge,
die der Kunde das zu benutzen hat,
sondern der kann da halt wild hin und her surfen.
Und keiner weiß, was als erstes und als zweites passieren wird.
Aber wenn ich nicht typische und realistische Reihenfolgen mache,
dann kriege ich halt nicht mit, dass die personalisierten Empfehlungen,
die ganz aufwendig zu berechnen sind,
in meinem Lasttest gar nicht berechnet werden,
weil ich in der falschen Reihenfolge die Seiten aufrufe und deshalb immer keine personalisierte Historie vorliegt,
anhand derer man eine personalisierte Empfehlung berechnen könnte.
Also da, es gibt so viele Fallstricke,
in die man da reinlaufen kann.
Für mich gibt es da eigentlich nur ein Credo. Wer versucht,
einen Lasttest Whitebox-mäßig durchzuführen, also zu sagen,
ich weiß ja genau, wie mein System aufgebaut ist.
Und deshalb schneide ich meinen Lastest jetzt so,
dass er die von mir als kritisch erkannten Punkte testet
Über sie zielsicher die Punkte, an denen seine Lösung krachen wird.
Kommen wir nachher auch nochmal drauf. Also wirklich versuchen einfach das,
was man im realen Betrieb erwartet, möglichst genau nachzubilden.
Da kommen dann auch Think Time mit rein und das ganze Thema der Datenvielfalt.
Es bringt nichts, hunderttausendmal denselben Artikel aufzurufen. Der kommt dann
wahrscheinlich aus dem Cash. Sondern man muss dann eben,
wenn man hunderttausende Artikel hat, auch hunderttausend verschiedene Artikel aufrufen.
Kannst du einfach sagen, was das Gegenteil bedeutet?
Think Time, Nachdenkzeit.
Der echte Kunde
Klickt ja nicht sofort weiter. Aus der Sicht des Ressourceneinsatzes
heraus ist es natürlich für die Lastgeneratoren am günstigsten,
wenn die ohne Unterbracht, unter UNO-Unterbrechung klicken.
Damit kann ich zwar dann meine Lastagenten optimal nutzen, habe da das Problem,
dass die gleichzeitige Anzahl von offenen Connections geringer ist als in Realität.
Weil die Browser halten ja die Connections auf und schicken People Lives,
damit die länger sind. Das heißt, so ein Engpass,
das sich irgendwie zu wenig Filehandels eingestellt habe oder die maximale Anzahl
von Connections und von neu aufgemachten Connections zu klein dimensioniert ist,
Die wird mir nicht auffallen, wenn ich nur wenige Lastgeneratoren haben,
die mit maximaler Power Requests abjagen,
weil ich dann zu wenig Gleichzeitiger habe.
So, und dann muss ich eben sowas wie Singtimes mit einbauen,
um meine Lastgeneratoren dazu zu zwingen, genug parallele Connections aufzumachen,
sodass ich tatsächlich einen Lastmix ergibt,
wie er in Realität ungefähr auftreten würde.
Ganz eigenes Thema bin Maske, das ist möglichst seriöstisches Userverhalten auch zu simulieren.
Ja. Und das beleitet für die Tools,
dass man solche Dinge, wie das liegt,
halt auch ein paar Leute interessiert mit einem Bus.
Jo, ich brauche zufällige Lasttests. Weil das ist ja
bei jedem Durchlauf anders. Das bringt mir nichts,
denn wenn ich einen deterministischen Durchlauf habe,
selbst wenn der die komplette Last produziert, dann weiß ich,
dass diese Art von Durchlauf funktioniert.
Aber jeder weiß ja, im Detail,
wie oft er schon mal mit irgendwelchen Race Conditions zu kämpfen hatte,
die tauchen halt und da lasst auch auf.
Und wenn es einen deterministischen Ablauf gibt,
dann werde ich eben nur einen ganz kleinen Anteil dieser
Race Conditions in meinem Lasttest bemerken
So, und dazu gehört dann sowas,
zufällig Testdaten wählen, zu viele Sessionlängen, zufällige Warenkorbgrößen,
die Singtimes müssen auch variiert werden, also nicht nur,
dass sie konfigurieren können muss,
sondern die müssen auch wiederum so ein Intervall haben,
in dem sie so schwanken können.
Alles mögliche Reihenfolgen, all das muss zufällig sein eigentlich,
um einen möglichst realistischen Lasttest zu haben. So,
in der Praxis ist bei uns ein Pattern rausgekommen,
was nahezu überall immer wieder vorkommt dann in unseren Lasttest,
nämlich gewichtete Zufallsauswahlen
Die Artikel werden ja nicht gleich häufig aufgerufen, zum Beispiel.
Da gibt es welche, die ganz häufig von Kunden angeklickt werden, welche ganz selten.
Der Aufwand, so einen Artikel darzustellen, ist aber unterschiedlich groß.
Hat damit zu tun, welche Empfehlungen da dran hängen,
welche Kundenbewertungen da dran hängen, wie viel Bildinformation,
Videos da mit da sind, was da angezeigt wird und,
und, und, und, und.
Deshalb sind Artikel unterschiedlich schwer für so ein System,
wenn ich einen realistischen Lasttest bauen will,
dann muss ich halt die Artikel,
die verschiedenen nicht nur zufällig auswählen,
sondern auch mit der ungefähren Häufigkeit,
mit der
sie aufgerufen werden
Jetzt haben wir ja ein sehr detailliertes Tracking.
Für uns ist es jetzt ganz einfach,
wir ziehen uns aus dem Tracking CSV-Dateien ab,
wo wir wissen, welche Seiten werden wir häufig aufgerufen,
welche Kategorien werden wir häufig aufgerufen, welche Suchbegriffe werden wir häufig benutzt.
Und, und, und, und, und.
Wie lang sind die Session im Schnitt? Wie groß ist
die Warenkörper im Schnitt? Wir haben sogar eine Häufigkeitsverteilung,
können dann sagen, also Warenkörper mit einem Artikel drin sind.
27 Prozent und welche mit zwei Artikeln sind,
sind 33 Prozent und, und, und, und.
So, jetzt haben wir lauter CSV-Dateien mit relativen Häufigkeiten
und wir haben einmal den Mechanismus gebaut,
der nimmt einfach diese Häufigkeitsverteilung und wird dann zufällig entsprechend
dieser Häufigkeit irgendwas dran aus
Und das können wir jetzt an allen Ecken und Enden immer wieder diesen Mechanismus benutzen.
Das wird doch im Prinzip den Effekt von den Bots,
weil typischerweise in den Webtracking tauchen die nicht auf.
Ja. Und die sind ja ganz heftig irgendwie denen,
die sonst nicht gecasht sind, nicht Top 3000 Longtail,
um den abzurufen. Ja. Wenn du das machst,
vertrauen wir wieder. Ja, Gott sei Dank haben wir
sowohl ein technisches als auch ein fachliches Tracking.
Und aus dem fachlichen Tracking nehmen wir die echten User-Daten raus und aus dem technischen Tracking,
wo die Hits auf die Server gezählt werden,
können wir die anderen Sachen rausziehen.
Und genau das tun wir auch.
Davon war abgesehen, weiß man aber auch anhand seiner Sidemap
Ganz gut. Welche Seiten bei jedem Durchlauf gemacht werden,
nämlich die ersten in der Sidemap, welche seltener gemacht werden,
die weiter hinten sind und welche von den Suchmaschinen fast gar nicht gemacht werden,
die da nicht drin auftauchen und die auch nicht groß verlinkt sind und eine Suchmaschine macht sich nicht die Mühe,
die eine Seite dann mehrfach aufzurufen,
wenn sie einmal ihren Durchlauf macht.
Also das kriegt man auch,
selbst wenn man dieses technische Geschichten und Auswertung nicht hat,
könnte man das auch darüber
einigermaßen gut hinkriegen
Ja, also gewichtete Zufallsauswahl taucht immer wieder auf. Wir ziehen uns dann regelmäßig,
lassen wir uns per Mail zuschicken aus unserem Tracking,
die CSV-Dateien zu, packen die mit unseren Lasttestkonfigurationen rein und wissen,
unser Lasttest entspricht zu jeder Zeit ungefähr dem,
was die Benutzer tatsächlich im Shop tun und benutzen.
Und wenn das sich im Laufe der Zeit entwickelt und über zwei Jahre,
wie das Projekt jetzt lief,
hat es sich ganz schön entwickelt,
dann merkt unser Lasttest das einfach und entwickelt sich mit,
ohne dass wir jedes Mal wieder was neu programmieren und anpassen müssen.
Ja, Auswahl, Suchbegriffe, nehmen wir Top-Suchbegriffe,
wir schaffen da bei der Test-Schritt-Reihenfolge, ThinkTime und sowas alles.
So, dann braucht man eine regelmäßige Last-Tests.
Ziele erreicht man nicht auf Anhieb. Und wenn man sie
einmal erreicht hat, dann ist nicht gegeben,
dass man sie am nächsten Tag mal noch erreicht.
Ich habe jetzt dummerweise die Grafik noch nicht fertig.
Ich wollte das unbedingt mal machen. Wir machen tägliche Last-Tests.
Und wir haben so das ganze System bewusst so abgestellt,
dass wir nicht nur die Fertigenversion zur Abnahme dem Lasttest unterziehen,
sondern auch schon die
ganz frischen Entwicklungsversionen
Das, was aus der Continuous Integration rauskommt, jede Nacht,
das wird wieder getestet. Insofern haben wir auch häufig mal Releases dabei,
die ihr Buggy sind, was dann unsere Lasttestergebnisse verhagelt.
Aber wir haben so ganz typisch so nach Lenin einen Schritt vor, zwei zurück.
Also man erreicht einen neuen Spitzenwert und am nächsten Tag kann man die Uhr nachstellen,
ist was Neues kaputt und es geht wieder irgendwas nicht und es dauert wieder zwei,
drei, vier, fünf Tage,
bis wir diese ganzen Bugs rausbekommen haben,
an die Teams adressiert haben, die das gefixt haben,
die Ops-Leute in der Umgebung,
was angepasst haben,
bis wir wieder
ein gutes Lastesergebnis kriegen
Das ist natürlich schon so ein bisschen diesen Umstand geschuldet,
dass wir da ganz frische Software nehmen, die eben nur minimal getestet wurde.
Aber es ist eben auch generell dem Problem geschuldet,
dass mit jeder neuen Entwicklung man das, was man erfolgreich erreicht hat,
wieder kaputt gemacht haben kann. Insofern muss man einfach,
man kann sich nicht auf diesen Lorbeeren ausrücken,
ruhen und sagen, okay, lasst erreicht, fertig,
lasst Tests in die Ecke stellen und ein halbes Jahr später wundert man sich,
dass es nicht mehr funktioniert.
Das Ding ist richtig,
dass hier einer eins zu eins kommt,
die Umgebung hat,
indem wir
unsere täglichen Last-Tests anfangen
Wo Leute auch machen. Ja. Also,
ich sag mal, bei uns ist es jetzt so
ein zugegebenermaßen relativ einfach, so was rechtfertigen zu können.
Einen Tag schlechte Performance oder einen Tag nicht funktionierender Shop oder
sehr schlecht funktionierender Shop kostet 20 Millionen.
Okay. In Betracht dessen ist der Aufwand für die Lastes
fangen müssen. Achtet dann die Möglichkeit,
Zum Beispiel einen Montagabend zu nehmen, also alles zu doggen,
der so abläuft und das dann als Testdatum zu genügen bin.
Machen wir so nicht. Komme ich nachher nochmal drauf,
wenn wir über die Tools sprechen. Das ist ja sozusagen
der Ansatz. Ich schneide den Traffic mit, der in
Realität passiert und spiele den in meinem System wieder vor.
Komme ich nachher nochmal, machen wir so nicht.
Könnte man auch machen. Gibt das auch welche,
die das erfolgreich tun? Für das, über das,
wie führen wir da kommt nachher nochmal drauf?
Agile Entwicklung war immer in zwei Wochen oder vier Wochen oder Biogolagen zu den habe.
Ich muss ja nicht unbedingt immer das Ein 1-zu-1-System testen,
wenn ich zumindest alltag abgeschrecktes System, aber auf dem ich das Delta sehen kann.
Ja. Das heißt, das lief mir dabei schon mal kriegen,
welche, zumindest ein sauberes System hat, wo ich weiß,
das System hat sich nicht verändert, aber ich sehe halt,
dass die Software, die Softwarestelle auch investiert, verhalten.
Ja. Das reicht zumindest schon mal, dass man sehen kann,
wenn prokulent ist, vielleicht gibt es ja viel,
aber auch scheiße entwickelbar gewesen.
Ja, also wir haben auch verschiedene Umgebungen,
die sind auch verschieden groß und je nach Sizing der Umgebung
ist dann auch der Lasttest verschieden groß.
Genau das kann man tun. Und um jetzt
den Punkt noch mal so ein bisschen vorwegzugreifen,
also wir arbeiten auch in einer Infrastruktur,
die auf virtualisierten Servern aufsetzt
Und wo wir in unseren Testumgebungen auch ein SIN-Provisioning oder Overcommitment machen können.
Das heißt, wir vergeben auf unseren virtualisierten Maschinen-Mehr-RAM und mehr CPUs,
als wir in Wirklichkeit haben. Diese Lasttests laufen in der Nacht,
wenn die ganzen anderen Testumgebungen von den Leuten,
die da täglich arbeiten, die nicht benutzt werden.
Insofern ist unsere Lastumgebung erstmal nur scheinbar so groß und teuer wie live,
weil sie eben nur temporär zu diesem Zeitpunkt frei verfügbare CPUs
und Kurs und so Also auf die Art und Weise,
über Virtualisierung und sowas,
kann man die Kosten für so eine Lastumgebung auch in begrenztem Maße wieder reduzieren.
Das zweite ist, dass wir tatsächlich,
dass wir mit der Ausfallsicherheitslösung kombiniert haben,
bei so einer großen Lösung braucht man ja auch irgendwo Vorarbeiten dafür,
dass ein komplettes Rechenzentrum ausfällt.
Du musst halt ein Notfallrechenzentrum geben mit den Ressourcen,
die man braucht, um die Live-Umgebung da wieder machen zu können.
Und de facto, wie sieht es jetzt so aus,
dass unsere Lastumgebung im Notfallrechenzentrum läuft
Ja. Ja, wenn ihr jetzt zufällige Testszenarien vertragt,
die die Möglichkeit, die eins zu eins wieder nachzustellen im Nachhinein,
also weil es gibt ja manchmal Fehler,
die müssen noch eins zu eins reproduziert werden und wenn das
dann nun mal so völlig läuft.
Naja, so, wenn es zufällig läuft,
kriegen wir es nicht eins zu eins reproduziert.
Ich check das nicht irgendwie mit und könnt das Gleiche dann
nochmal haben. Das haargenau gleiche nicht, nein,
wir können denselben Mechanismus mit denselben Wahrscheinlichkeiten und denselben Basisdaten
nochmal laufen lassen und der wird wieder was,
das Lastverhalten anbetrifft,
ein ähnliches Ergebnis bringen
Aber genauso wie der Traffic am Montag und am Dienstag sich
eben dann doch unterscheiden und man nie den realen Kundentreffic wiedersehen wird,
der an einem Tag war.
So ist das auch in unser Last. Das geht aber
auch nur. Wahrscheinlich werden alle nicht am kompletten Fehler. Naja,
aber es geht wieder, ich meine,
wir sind ja alle Entwicklungen, es gibt ja auch manchmal Kern,
es gibt gewisse Konstellationen und ganz,
ganzes Fehler auftreten in Richtung diesen ganzen gewissen Fehler einmal habe und ihn dann hinterher nicht mehr finden oder wie?
War das dann ja genug? Ja, nicht nur das
. Wir können das ja abkürzen. Also,
mit unserem Lasttest haben wir die gleiche Situation wie mit einem Fehler,
der am Live-Betrieb auftaucht,
Wenn diesen Fehler kann ich auch erstmal nicht reproduzieren und nicht reproduzierbare Fehler, kann ich ganz schlecht die buggen und fixen.
Wenn sich dieser Fehler im Live, nach dem einen Mal,
wo er aufgetreten ist, 365 Tage lang nicht mehr zeigt,
dann kann ich Ihnen beruhigt zu den Akten legen,
dann ist das wahrscheinlich doch eine seltene Einmalkonstellation gewesen.
Wenn er immer mal wieder auftaucht,
dann taucht er auch in unser Lastes immer mal wieder auf,
weil die ja in den gleichen Gesetzmäßigkeiten unterliegen und die Kunst liegt dann in unseren Lasttests genauso wie auch im Live-Betrieb darin,
dafür zu sorgen, dass sich im Falle so eines Falles,
dass ich selten auftretende Fehler habe,
ich möglichst so viel mit protokolliert habe,
dass ich trotzdem in der Lage bin,
im Nachhinein was zu analysieren und rauszufinden.
Auch wenn ich den Fehler so nicht reproduzieren kann,
dass ich ihn zumindestens eigentlich einkreisen kann und die Ecke in meiner Anwendung identifizieren kann,
womit das irgendwas zu tun haben muss.
Und dann kann ich gezielte Lastszenarien machen,
die nur diesen einen Fall stressen und da hoch und runter testen,
bis ich das so halbwegs reproduziert bekomme.
Also muss schnell zurückgehen. Ja,
also in der Praxis haben wir automatisierte Komponentenlastes,
die von den Entwicklern gebaut werden,
die die einzelnen Komponenten bauen
Und die dann auch in der Build-Pipeline der Komponente automatisch mitlaufen. Dann gibt es dann irgendwelche Jenkins-Stops,
die irgendwelche J-Mieter-Lasters mitmachen und wo dann auch das Release,
was da gebaut wurde, damit bewertet wird, hat es das erfolgreich bestanden.
Und dann gibt es anschließend die automatisierten täglichen Systemlasttests,
über die ich jetzt größtenteils rede,
wo wir eben nicht nur an einer einzelnen Komponente, sondern dieses Gesamtzusammenspiel testen.
Und neben dem, was da täglich läuft,
gibt es dann tagsüber auch noch viele individuelle Lasttestläufe,
wo dann gezielt irgendwas ausprobiert wird, was weiterentwickelt wird,
geguckt wird, ändert dieser Parameter jetzt was?
Und wenn ja, dann lasse ich ihn oder Ja, so.
Und wir sind jetzt dabei zusätzlich zu diesem Lasttest,
die was herausfinden soll, noch in die Continuous-Delivery-Pipeline,
wo dann automatisiert Sachen live gestellt werden sollen,
so ein Kurzabnahmelasttest zu machen, der da einfach eine halbe Stunde mitläuft,
parallel zu den funktionalen Abnahmetests, um so ein Gate zu haben,
wenn der nicht gut ist, dann geht es einfach nicht live.
Weil wir darauf umstellen wollen, dass tatsächlich Releases
ohne menschliches Zutun automatisiert live gehen.
Ohne dass nochmal jemand drauf geschaut hat und gesagt hat,
ja,
darf gehen
So, und das sieht dann irgendwie so,
gibt es so einen Prozess, der da definiert ist,
wie das so durch verschiedenen Stufen durchläuft.
Und dann gibt es parallel zu diesen Sachen jetzt auch noch automatisierte Performance-Messungen, Lastes.
Also wir machen neben den Nast-Tests immer auch noch Performance-Messungen,
die werden mit Webpage-Tests gemacht und die werden jetzt dann auch so integriert,
dass wir dann parallel zu diesem Last-Test auch nochmal mit einem synthetischen Messtool die echte Seitenperformance messen.
Weil ich natürlich mit der Last nur dann einverstanden bin,
dass die erreicht wurde,
wenn die Antwortzeit meiner Seiten unter dieser Last
immer noch
meine Ziele erfüllen
Also es ist nicht eine reine Durchsatzbetrachtung, das bringt mir überhaupt nichts,
wenn das System den ganzen Durchsatz wuppen kann,
aber es dauert 20 Sekunden, bis die Seite da ist.
Na gut, jo, Tool, Frage. Es gibt die
verschiedensten Art und Weisen, wie man sowas machen kann.
Das fängt irgendwie so an, dass ich irgendwie einfach synthetisch
harte TP-Request-Last erzeuge. Einfach sage, hier, die URL,
20 Sweats, so viel du kannst, mach mal.
Das AB ist hier, das Apechy-Bench ist im Apechy-Webserver so
ein kleines Tool mit dabei, kann man das ganz schnell machen.
Es gibt Unmengen von Tools, die das können.
Ich habe mal ein Open-Source-Tool, Jemita genannt,
ein käufliches Zilt-Performer, um sowas zu machen.
Dann gibt es Capture, Replay von realem Traffic.
Das kann man auch mit diesen Tools machen. Das heißt,
da wird mitprotokolliert, was ist der HTTP-Traffic,
der auf die Server einprasselt und dann wären die,
wird dieser HTTP-Traffic einfach später nochmal den Servern vorgespielt.
Dann gibt es den Weg, Browser zu simulieren.
Das sind dann zwar nicht echte Browser, sondern irgendwelche Heatless-Browser,
kann man mit HTML-Unit machen, kann man mit Phantom GS machen.
Also es gibt so verschiedene Tools, mit denen man das machen kann,
damit der Aufwand nicht ganz so groß ist.
Und hat den Vorteil, weil das echte Browser sind,
nicht nur irgendwelche HTTP-Request-Generatoren, laden die dann automatisch alle statischen Ressourcen,
die auf einer Seite drauf sind, auch tatsächlich mit,
ohne dass sie es programmiert haben muss.
Die führen auch das JavaScript aus und setzen die AJX-Calls mit
genau dem Timing und den Inhalten ab,
die auf der Seite dahin gehören,
weil sie eben das Verhalten eines Browsers haben
Dann gibt es auch noch den Weg, dass sich der
echte Browser fein steuere. Da gibt es von Atlessin-Tool,
nennt sich Soak, wo man das mitmachen kann.
Ich könnte theoretisch auch hier irgendwie mit Win-Runner viele echte Rechner automatisieren,
um das zu produzieren, diese ganze Last.
Und ich kann natürlich auch sagen,
ich habe hier so ein Lab an der Hand,
die haben hier 2000 echte User und denen gebe ich
ihr Testskript mit und die hacken dann drauf rum,
um meinen Lasttest zu machen.
Zugegebener Mast ein bisschen teuer, diese Bayernte. So,
und der Trade-Off, den ich mir jetzt überlegen muss zwischen
diesen verschiedenen Stufen, ist, wie groß ist der Aufwand,
sowas hinzustellen
Wie groß ist denn der Aufwand, das am Leben zu halten,
dass es auch morgen und übermorgen und in einer Woche,
in einem Monat immer noch vernünftig testen kann?
Und wie sieht denn die Realitätstreue des Ganzen aus?
Und da haben diese verschiedenen Lösungen, verschiedene Vor- und Nachteile.
Und das ist jetzt meine persönliche Bewertung.
Da kann man auch anderer Meinung sein. Und vorhin gab
es ja diesen Fall mit diesem Capture Replay.
Das hat natürlich eine sehr gute Realitätstreue. Ich habe ja
realen Traffic, den ich abspiele. Es hat aber auch
ein paar Limitierungen. Nämlich in dem Traffic sind echte Session-IDs,
echte Zeiten und,
und,
und drin
Das kann durchaus sein, dass ich,
wenn ich das per Re-Play abspiele, das nicht mehr funktioniert.
Also wenn da irgendwo eine Bestellung ans Backend übergeben werden muss,
dann sagt die, die Session ist ja maueralt, die akzeptiere ich nicht mehr.
Den gibt es nicht mehr, das so. Dann kann ich anfangen per Skript,
diesen Traffic, den ich mitprotokolliert habe, zu modifizieren,
zu sagen,
okay,
und alle Timestand ersetzt du durch einen Akten einen Tagesstempel und
die Session-IDs musst du so umkonvertieren und die Warenkorbnummern und schießt mich tot,
was da so alles so spezifisch ist und nicht mehr geht beim Replay,
musst du anpassen
Und dann bin ich oft da einmal in einer Situation,
wo das eine ganze Menge Aufwand wird,
das am Leben zu erhalten und zum Funktionieren zu bringen und zwar vollumfänglich,
weil wir ja nicht statische Webseitenaufrufe in erster Linie in unseren Lasttest wollen,
sondern Anwendungen,
die da gesteuert werden.
Insofern ist der Pflegeaufwand da schon mal Mittel,
obwohl es ja eigentlich nur Capture ist.
Ich muss das zumindest mal regelmäßig capturen und dann muss ich diese Nachbehandlung machen.
Das größere Problem ist, das geht natürlich nur,
wenn die Anwendung eigentlich
schon live ist und im Pflegemodus ist
Weil wenn wir jetzt einen neuen Shop bauen,
dann ist da prinzipiell zwar nicht alles total anders,
aber den Traffic, den kann ich nicht nehmen von dem Alten,
um den Neuen zu befeuern.
Das heißt immer, wenn ich was Neues baue, geht das gar nicht.
Und für die Features, die ich dann neu baue,
in einer bestehenden anderen geht, das gerade auch nicht.
Ich kann damit immer nur einen Regressionstest für das Alte machen.
Das ist die ganz starke Limitierung dieser Variante.
Ich kann natürlich auch ohne Capture Replay einfach synthetisch
die Dinger programmieren und die HTTP-Traffic erzeugen lassen,
aber dann ist auf einmal
der Programmieraufwand
Deutlich höher, weil dann muss ich permanent untersuchen,
haben die schon wieder andere Ressourcen eingebunden?
Haben die schon wieder andere E-Checks-Requests eingebunden? Geben sie jetzt
andere Formatanweisungen mit bei den Ressourcen und, und, und, und, und?
Ich bin da ständig am Nachprogrammieren, war ja der Shop,
und das, was ich da testen will, sich ständig ändert, weil ich ja eine realistische Last erzeugen will. Und das alles hat dazu geführt,
dass wir uns, obwohl das Simulieren von Browsern deutlich höhere Hardware-Anforderungen hat,
als nur den Traffic zu erzeugen, uns entschieden haben,
bei uns den Weg zu gehen,
dass wir da tatsächlich ein Tool einsetzen,
das heißt Acceptance Low-Test ist von einer kleinen Firma,
ist irgendein Spin-Off für einen Intershop,
die sich Acceptance nennt und die haben um Selinium-Webbreiber und HTML-Unit drumherum sozusagen das Ganze und jetzt lasse ich das in Massen ablaufen und steuere das auf verschiedenen Agenten,
verteile diese Testausführung und sammle die Messwerte ein und baue Reports drumherum gebaut.
Und ja,
damit simulieren wir jetzt den Browser und haben irgendwann vor Monaten mal
unsere Testfälle gebaut und müssen alle Wochen mal an einer oder der anderen Stelle ein bisschen was ändern,
weil der prinzipielle Ablauf,
welche Art von Seiten aufgerufen werden und auf welche Links dann geklickt wird,
ändert sich ja gar nicht.
Auch wenn die Seiten sich permanent ändern, weil da immer
neue Features draufgebaut werden und das Timing der Seiten sich permanent ändert.
Jo, dann haben wir jetzt sozusagen die Anforderung.
Wir wissen, welche Last es wir machen wollen.
Wir haben uns irgendein Tool ausgewählt und gehen dann den
bitteren Weg zu Ende und bauen diese Last-Tests.
Jetzt müssen wir sie, nachdem wir sie ausgeführt haben, auch noch auswerten.
Also ich habe ja nur davon gesprochen, jetzt zu wissen,
welche Last ich generieren will und sie generieren zu können,
Da habe ich auch noch nichts gemessen und dann weiß ich auch noch nichts.
Und darum soll es jetzt so ein bisschen gingen.
Wie funktioniert das? Also, de facto haben wir jetzt 50 Lastgeneratoren,
A8 Kurs, also 400 CPU-Kerne und 400 Gigabyte Hauptspeicher,
die in unseren Lastgeneratoren und Messumgebung drinstecken, um die Last zu erzeugen.
Das ist eine ganze Menge Holz. Das ist ungefähr 70
Prozent des Systems, das wir testen.
Jetzt kann man sich aber auch überlegen,
also wir versuchen ja irgendwie, den Traffic nachzustellen,
den 100.000,
200.000 Kunden machen
Wenn ich das mit 50 Maschinen hinkriege, ist das gar nicht so schlecht.
So, dann gibt es drei verschiedene Testumgebungen, auf die wir unser Lasttest machen.
Wir machen tatsächlich, haben noch den Luxus,
dass wir auf die Live-Umgebung auch Lasttests fahren können,
weil das alles noch in einem frühen,
früher mal Alpha jetzt Beta-Modus ist und das alles noch im Einfahren begriffen ist.
Später werden wir das wahrscheinlich nicht mehr dürfen können,
aber es gibt eben für die Entwicklungsseite den Lasttest
eine Umgebung und für die Abnahmelast Tests eine zweite Umgebung,
weil das ja auch gleichzeitig passieren können soll mit unterschiedlichen Software-Releases.
So, und neben den Lastgeneratoren, die da die Last drauf geben,
gibt es jetzt noch zwei wichtige Systeme, die hier schon mal stehen.
Graffite und Splank, die ich zum Auswerten mitbrauche.
Weil was mache ich denn jetzt hier? Ich messe an dieser Stelle,
der Klein greift auf das System zu, wie schnell das System antwortet.
Und das werde ich natürlich auch aus. Ich weiß,
alle Requests, die wir gegen die Server absetzen,
ich weiß, wann ich sie abgesetzt habe,
wie lange es gedauert hat, bis das erste Bei zurückgekommen ist,
wie lange es insgesamt gedauert hat,
wie viel Bytes da übertragen wurden,
wie lange der Aufbau der Seite gedauert hat,
kann ich
alles da messen
Nur das, was ich in den Systemen dann tut,
während ich diese Last erzeuge, warum die Antwortzeit schlecht ist,
sehe ich natürlich hier nicht,
weil ich habe ja Blackbox-Sicht, ich bin draußen.
Um aber jetzt nicht nur zu wissen, shit,
war doof, sondern auch zu wissen,
warum war es denn doof, wo war es denn doof,
wer muss denn jetzt als Entwickler ran und das analysieren und das fixen,
muss ich auch eine Innensicht in das System kriegen.
Und dafür brauche ich das. Was wir machen ist,
wir schreiben in den verschiedenen Systemen, die wir gebaut werden,
Profiling-Logs mit, die alle nach Splank transportiert werden.
Und wir haben auf all den Maschinen auch noch verschiedene Monitoring,
Props laufen, die diverseste Metriken nach Graphic wegschreiben, über das Verhalten dieser Server.
So, und damit bekomme ich eine wunderbare Sicht darauf,
welche fachliche Aktivität in meinem System hat da im Zuge des Aufbaus dieser Seite wie lange gedauert.
Da sind auch die Datenbanktransaktionen mit drin, die gemessen werden,
wie lange hat irgendwelche Queeres gedauert, da sind Serviceaufrufe,
Controller, je nachdem, aus welchen Elementen sich die Anwendung zusammensetzt.
Das kriegt man heute per Run Runtime-Veabing oder aspektorientierter Programmierung
ja zumindestens in der Java-Welt sehr einfach geschenkt,
dass man das querbeet über alles machen kann, Performance-Werte mit erzeugen kann.
Und das kann dann auch zielgesicherter sein,
die Punkte sein, die mich wirklich interessieren,
ohne jetzt einen echten Pro-Filer anschmeißen zu müssen,
der alles mit protokolliert und damit natürlich auch mein System wieder
langsamer macht
So, und das wird dann alles ins Blank gesammelt.
Während hier werden auf der einen Seite Metriken gesammelt,
die auf der Ebene des Betriebssystems sind, Hauptspeichernutzung, CPU-Ausnutzung,
Plattenausnutzung, Platten-IO-Operation, Netzwerktraffic und, und, und.
Aber auch in den Ebenen da drüber. Also wir holen uns dann
auch die Kennzahlen aus den VMs, um zu sagen,
wie oft ist der Garbage-Collector angeschmissen worden, wie viel Garbage-Collection-Time war da,
wie viel Platz war auf dem Hieb frei.
Wir gehen auch noch eine Ebene höher und sagen,
okay, der Tom-Kit hat einen Sweatpool,
den er verwaltet und der hat einen Connection-Pool,
wie viel davon war genutzt,
wann lief das an Grenzen
Sind sozusagen die verschiedenen Ebenen von dem Blech bis zu dem,
was unsere Anwendung inhaltlich tut, auch nochmal als Kennzahlen in Graphic drin.
So, jetzt haben wir sozusagen sowohl eine Sicht von außen
auf die Anwendung als auch eine Sicht auf die Internas der Anwendung,
als auch eine Sicht auf alle Ressourcen,
die von dieser Anwendung genutzt werden.
Und wer schon mal nach Performance und vor allen Dingen auch Last geguckt hat,
weiß, es geht immer darum, den Ressourcenengpass zu finden,
weil wenn die Performance schlecht wird, dann ist irgendein Ressourcenengpass aufgetreten.
Also wenn die Performance unter Last schlecht wird.
Und dann geht es immer darum, den Ressourcenengpass zu finden,
deshalb keinen Lasttest machen und auswerten,
ohne eine Sicht auf die Ressourcen haben zu können
So, was machen wir jetzt mit den Ergebnissen, die da so rauskommen?
Also wir gucken dann zum Beispiel auf den Durchsatz,
den wir geschafft haben. Das war diese erste Kurve,
wo ich gleich auf den ersten Blick jedes Mal sehe,
ich rufe mir einen Lasttest-Report auf, war das gut.
So, jetzt versuche ich mal, das live hinzukriegen.
Grau ist alle Theorie, wunderbar. Schein funktioniert zu haben.
Das ist der Lasttest vom Montagfrüh. Da sehen wir,
wir sind schon ziemlich dicht an unserem Zielbild dran.
Also irgendwie Sie zählen ja aus,
hier hinten dann nicht mehr so richtig, aber ziemlich gut.
Und wenn wir so diese anstrengende Last machen,
dann gibt es so ein paar Zielpunkte, die wir uns immer anschauen.
Wir haben aus unseren Lastanforderungen heraus eine Definition,
was ist 100 Prozent Last? Und unseren Lasttest mit ansteigender Last
lassen wir immer von 0 bis 200 Prozent laufen.
Weil wir wollen ja nicht nur gucken, ob das,
was er unbedingt können muss, abkann, sondern auch,
ob es danach noch weitergeht.
Das heißt, in dem Lasttest müssen wir unbedingt
bis hierhin kommen,
haben wir
locker geschafft
Aber wir sind ja jetzt noch nicht beim Endausbau, sondern wir sind noch ein Meilenstein vorher.
Es kommt jetzt noch mal ein Meilenstein. Also das Ziel,
was ist die 100 Prozent, die wir können wollen?
Wird noch erhöht werden? Und sobald ich das umgebaut habe,
ist dieser Punkt dann ungefähr hier. Also wir müssen schon noch ein Stückchen weiterkommen. So,
was man auch sofort sieht,
wenn man sich die zweite Kurve anschaut, ist,
dass das besser aussieht, als es in Wirklichkeit ist,
weil wir Folgendes machen, damit diese Kurve genau das aussagt,
was wir wollen, erzeugen wir die Last nicht so,
dass wir sagen, mach mal erst einen User,
dann zwei User, dann drei User.
Und der macht die Aktion, dann wartet er eine Sekunde,
dann macht er die Aktion im Warter,
dann eine Sekunde,
dann macht er nächste Aktion,
wartet eine Sekunde
Das heißt, wir definieren nicht die Anzahl der simulierten User,
die was tun und was sie da tun,
weil das sofort dazu führen würde,
wenn unser System langsamer antwortet, dann schafft er natürlich weniger.
Weil er mehr warten muss. Das heißt,
wir haben dann keine Linie, ansteigende Last mehr,
die wir produzieren, sondern die Last,
die wir produzieren, hängt vom Antwortzeitverhalten ab.
Das Tool hat jetzt eine Möglichkeit, dass sich eine sogenannte Arrival Rate vorgebe.
Das heißt, ich sage dem Tool, wie viel Last soll es produzieren?
Und wenn das mit der Anzahl der simulierten Benutzer das nicht mehr hinkriegt,
dann fährt es einen weiteren simulierten Browser-Sweat hoch und steigert
die Anzahl der User quasi immer weiter,
um die Last an Requests zu produzieren,
die ich nachstellen will
Das heißt, in dem Moment, wenn mein System anfängt,
in seinen Antwortzeiten einzubrechen, bricht nicht sofort die Lastkurve ein.
Aber die Anzahl der simulierten User steigt da an.
Und dann sehen wir, dass wir sozusagen hier zwei markante Punkte haben,
hierhin, steigt die Anzahl der simulierten User steil an.
Die wird dann nur dadurch begrenzt, dass ich irgendwo gesagt habe,
aber nicht mehr als so und so viel User.
Das heißt, mein System ist am Anschlag eigentlich da.
Aber wir haben auch davor schon einen Punkt,
wo hier die Anzahl der User auf einmal einen Sprung macht
von 600 auf 800 simulierte User um diese,
also simulierte Browser
Um da die Last an dem Punkt nachzustellen.
Das heißt, wir haben eigentlich sofort zwei Punkte.
Wir sehen, dass wir insgesamt ziemlich dicht dran sind.
Wir sehen sofort auch zwei Punkte, wo irgendwas passiert ist.
Und jetzt fängt es an zu sagen, ja,
okay, was ist denn da passiert?
Weil wir haben jetzt ja noch nicht drauf geschaut,
war, dass die Homepage oder was,
welche Seite hat er da aufgerufen und was ist da eigentlich langsam geworden und dergleichen mehr.
Also geht jetzt die Untersuchung weiter und dann gucken wir als nächstes da drauf,
dass wir hier uns Sicht auf die einzelnen Aktionen,
das sind die einzelnen Seitenaufrufe, die der da tut,
machen,
Und dann steht hier irgendwo, kann man hier nicht lesen,
da ist der Aufruf eines Produktes und die verschiedenen Sachen.
Das ist leider, ja, gut,
ich mache jetzt hier RDP-Session auf meinem Rechner bei Otto und das Ganze,
in dem Ding kriege ich irgendwie jetzt nicht scharf hin.
Fakt ist, ich sehe hier meine Seitenaufrufe. Ich sehe hier
die Laufzeiten dieser Seitenaufrufe, Media, Minen, Minen,
Max, Standardabweichung. Und das ist nicht der Aufruf des Requests,
sondern der Aufruf der Seite, inklusive JavaScript, inklusive Ressourcen runterladen.
Also das Ganze, das kann ich schon annähernd mit dem,
was ich auch bei den Kleinen seit den Performance-Messungen messe, vergleichen.
Das ist nicht deckungsgleich. Der braucht ja nicht Rändern,
ist er schneller, aber der hat eine nicht so leistungsfehle JavaScript-Engine,
ist er langsamer, je nachdem,
wie das Mix zwischen Rändern und JavaScript auf der Seite ist,
sind die Zeiten mal besser und mal schlechter,
als die richtiger Browser messen würde.
Aber sie sind von der Größenordnung ungefähr da, wo wir hinwollen.
Ich sehe es fort, wo es Fehler gab,
dass da irgendwie bei diesem Aufruf ganz viele Fehler sind,
da so ein paar vereinzelte.
Und dann kann ich jetzt als nächstes mir anschauen,
nachdem ich diesen Überblick habe,
wie sieht jetzt sozusagen dieses Laufzeitverhalten für einzelne Seiten aus
Und das ist jetzt, das Graue ist sozusagen der Bereich,
in dem die Laufzeit der Seite zu dieser Sekunde geschwankt ist,
das Blaue ist der Mittelwert,
kann ich mal die Entwicklung der Mittelwert,
den mir hier noch ein bisschen rausholen.
Und dann sehe ich halt, dass genau diese zwei Punkte,
die wir vorhin bei den Usern gesehen haben,
sich in dieser Aktion auch zeigen.
Hier wird sie langsamer und dann wird sie ab dem Punkt
nochmal deutlich langsamer. Und danach geht es auch steil nach
oben mit der Laufzeit dieser Aktion. Das heißt,
hier ist das System bezüglich dieser fachlichen Aktivität schon in einem Zustand,
in dem ich es nicht haben will.
Ich komme mit der Last noch irgendwie klar,
es bricht nicht ab,
aber von linearer Skalierbarkeit ist da schon lange nicht mehr
die Rede
So, und das Interessante,
was ich jetzt in diesem Lasttest hier einigermaßen sehe,
ich habe noch einen Lasttest von heute eigentlich irgendwo hier.
Da sehe ich das noch besser. Ich mache mir hier nicht
zu viel rum jetzt. Fast alle Aktionen haben das Gleiche aussehen.
In diesem Lasttest. In diesem einen nämlichen Lasttest. Das heißt,
obwohl da ganz unterschiedliche Teile meines Systems getestet wurden,
verhalten die sich alle zum gleichen Zeitpunkt so,
dass sie auf einmal viel schlechter werden.
Lässt den Messerscharfen Rückschluss zu,
dass es wahrscheinlich nicht an der Fachlichkeit in dieser Aktion liegt,
dass sie da langsamer wird
Sondern an irgendwas, was die Dinge alle gemeinsam haben
. Weil sie durch dieselbe Netzwerkkomponente laufen, dieselbe Datenbank benutzen,
den selben Barnisch-Cash, weil sie irgendwas inkludieren,
was sie alle gemeinsam haben und, und, und, und.
Das heißt, ich kriege aus meinem Blackbox-Test schon so ein paar Hinweise darauf,
wo ich nach Engpässen und Problemen suchen muss.
Aber ich kriege nur Hinweise darauf, ich weiß es nicht.
Ich kann jetzt dann auch noch auf die Ebene der
einzelnen Requests draufgehen
Und dann sehe ich dann, welche Arten von Requests,
mit welchen Häufigkeiten waren und welche davon fehlgeschlagen sind und sehe,
dass hier nicht nur meine fachlichen Aufrufe vielgeschlagen sind,
weil das ist jetzt gerade irgendwas hier Static Assets von irgendeinem Asset-Server,
da werden statische Ressourcen geholt.
Und auch diese Aufrufe schlagen viel. Also es hat noch nicht
mal was mit unseren Anwendungsservern zu tun oder nicht nur mit denen. So,
also kann man jetzt durch so einen Lastest und durch so
eine Sicht relativ rasch einkreisen, wo es Probleme gibt,
aber man weiß nicht genau, welche es gibt.
Und das ist dann der Punkt,
wo man auf die nächste Ebene draufgehen muss,
bevor ich das tue und die nächste Auswertungsebene zeige.
So, jetzt. Hier nochmal so als Slides,
so ein paar typische Bilder, was wir in Lastes immer wieder sehen.
Das war das Verhalten, was wir jetzt auch schon mal gerade gesehen haben.
Irgendwann flacht diese Lastkurve ab, die Anzahl der Benutzer steigt extrem an,
weil auf einmal die Laufzeit explodiert dieser fachlichen Aktivität.
Da ist dann irgendwas an die Grenze gekommen. So,
auch ein typisches Bild ist sowas hier, Stau auf der Datenautobahn
Ganz typisches Stauverhalten, dieses Auf und Ab,
da ist irgendwas total überlastet, genauso,
wenn zu viele Autos versuchen, auf der Autobahn zu fahren,
dann gibt es einen Stau und dann ist der irgendwann zu
Ende und es geht wieder weiter und man fragt sich,
warum hat es denn hier gestaut und auf einmal steht man wieder und fragt ihn,
warum fragt sich es denn hier?
Das ist einfach, da ist zu viel unterwegs.
Da ist irgendwas zu eng für das, was da durch soll.
Was ist so was? Sieht man immer wieder,
wunderbar. Nächstes Thema, sowas,
mein System skaliert linear hoch und dann komme ich an den
Punkt und auf einmal bricht es ein und dann fällt das
auch alles in sich zusammen
Da ist irgendwas nicht lastresistent. Da habe ich einen Stresstest ungewollt gemacht.
Und es war so gestresst, dass es zusammengebrochen ist.
Und das ist auch noch eine interessante Beobachtung.
Was man sich meistens anguckt, ist die durchschnittliche Laufzeit.
Weil ein Lasttest, ich habe ganz viele Requests,
die da passieren. Ich kann nicht den einzelnen betrachten,
also gucke ich eben auf Durchschnittswerte. Und dann sehe ich,
ja, der Durchschnittswert ist ganze Zeit konstant und am Ende
steigt dann ein bisschen.
Scheinbar. In Wirklichkeit, das sehe ich an den
grauen Kurven,
passiert aber Folgendes
Die untere Kurve, das kann man jetzt ganz schlecht erkennen,
bleibt die ganze Zeit unten.
Also es gibt die ganze Zeit über schnelle Requests und schnelle Seitenaufrufe.
Dieser Bereich hier, wo noch viele Requests liegen,
der wird ein bisschen größer, aber nur unwesentlich.
Was wirklich passiert ist, dass es von Anfang an Ausreißer
gibt, die 30 Sekunden lang sind.
Wir haben unsere Timeouts auf 30 Sekunden an irgendeiner Komponente konfiguriert.
Und die Anzahl der Ausreißer nimmt zu. Nicht die einzelnen
Aufrufe wären wirklich langsamer, sondern die Anzahl der Aufrufe,
die gar nicht richtig beantwortet werden und die zu Timeouts führen,
die nimmt zu
Das heißt, ich habe ein ganz anderes Problem als eine
schleichende Verlangsamung meiner Antwortzeiten. Deshalb kann ich immer nur wieder sagen,
Durchschnitt ist gut und schön, aber das ist nicht alles.
Nicht nur auf die Durchschnittswerte gucken. Was schon mal hilft,
ist, wenn man nicht automatisch irgendwie auch noch Standardarbeit um sowas alles berechnet bekommt,
wenn man wenigstens den Minen und den Medien sieht.
Wenn die anfangen auseinanderzulaufen, ist Achtung angesagt,
da ist dann irgendwas im Argen, da muss man mal schauen,
was da in Wirklichkeit passiert.
So, live haben wir da schon drauf geschaut.
Wir kriegen also fährt ja HTML-Reports, die sind direkt in
unseren Lasttestläufen, die über Jenkins gestartet werden,
Ich komme da einfach früh rein. Das erste ist
Jenkins Aufrufen, Job vom letzten Lasttestaufrufen, Report-Anzeigen.
Und dann gucke ich als erstes genau auf solche Bilder,
weiß, wo stehen wir denn? Sah es gut aus
, sah es besser aus als gestern oder nicht?
Und ich habe sozusagen schon mit dem ersten Blick,
weiß ich sofort, ist es besser oder schlechter als gestern?
So, dann kommen die Splank Reports.
Da versuche ich eine Whitebox sich zu kriegen.
Ich versuche, in die Systeme reinzukriegen, reinzuschauen.
Da gibt es spezialisierte Performance-Logs, die müssen die Anwendung mitschreiben.
Das heißt, ich habe Entwicklungsaufwand,
sonst habe ich
diese Werte nicht
Mit Ausnahme von den Teilen, die ich per Konfiguration kriege.
Also wir schreiben zum Beispiel ein Tom Kit Access Lock weg natürlich und dem kann man konfigurieren,
dass da die Runtime mit drinsteht von den Aufrufen,
die an dem Tom Kit gemacht werden.
Da brauche ich nichts programmieren dafür, dann ist nur eine Konfigurationsoption. So,
dann muss man das alles einsammeln über die verschiedenen Maschinen hinweg,
weil das ist ja nicht ein Server,
den wir da untersuchen, über die Logfile-Typen hinweg.
Wir haben diverseste Logfiles, in denen irgendwas drinsteht,
was relevant ist beim Auswerten. Dann können wir da dynamische Adhoc-Queries machen,
das heißt, wir können in dem Moment,
wo ich jetzt in meinem Lasttestergebnis irgendwas gesehen habe, gezielte Auswertungen fahren,
die genau diesen Sachverhalt aus den vielen mitprotokollierten Lockdateien rausziehen.
Und das Ganze ist dafür da, explorativ untersuchen zu können,
was ist denn da genau passiert. Und ich kann tatsächlich
an dieser Stelle bis auf die Ebene des Einzelnen Requests runterdrüben.
Ich sehe jeden einzelnen Request mit seinen Parametern,
mit seinen Laufzeiten, auf welchem Server,
der durchgelaufen ist und, und, und, und.
Und daher kann ich, muss ich nicht unbedingt immer alles reproduzieren können,
weil ich kann es schon so sehr genau untersuchen.
So, die Herausforderung ist,
das Ganze besteht jetzt aus einem Dutzend separate Teilsysteme
Die von unabhängigen Teams entwickelt werden, eigene Release-Zyklen haben und
in Summe dann das System ergeben, was ich teste.
Und die wichtigste Frage, die ich eigentlich klären muss,
als jemand, der eine übergreifende Sicht hat, ist,
welches dieser vielen Teilsysteme war schuld?
Damit ich wenigstens das mal einkreisen kann auf das Team,
zu dem ich jetzt gehen muss, um zu sagen,
da war im Lasttest was und das sieht nicht gut aus,
guck doch mal bei dir rein in die Details.
Weil ich kann natürlich ein paar Auswertungsplank machen,
aber um dann genau zu wissen,
welcher Wert der da mit protokolliert wurde, was bedeutet,
braucht es einfach die Expertise von dem Team,
was das gebaut hat,
geht nicht ohne die Entwickler
So, wie kann man sich das so vorstellen?
Also es gibt jetzt viele verschiedene Vertikalen heißen die bei uns,
die sind jeweils für einen fachlichen Zusammenhang da.
Und da gibt es da eine sogenannte Frontend-Integration. Das läuft
über den Mechanismus, der läuft unter dem Stichwort Edge-Side-Inblut,
easy. Das ist ein Standard,
wird nicht so breit eingesetzt und führt letztendlich dazu,
dass ich eine Seite aus Snipplets, die von verschiedenen Systemen zugeliefert werde,
zusammensetze, und zwar auf Serverseite.
Ich könnte das, was da an Easy Inbluts gemacht wird,
theoretisch auch mit Eiframes auf der Browserseite machen
Da werden ja auch, wird ja auch die Gesamtseite aus Snipplets zusammengesetzt haben letztendlich.
Es gibt eine Rahmenseite und dann werden da Sachen eingebettet.
Nur wenn ich mir jetzt das Laufzeitverhalten vorstelle,
dann ist es natürlich wesentlich geschickter,
das Zusammenbauen aus vielen einzelnen Requests da von Server zu Server schnell mal eben zu erlililien,
als da jedes Mal zum Kleinen zurückzulaufen über,
keine Ahnung, was für Langstrecken netzwerktechnisch gesehen.
Jo. Heißt aber auch, ich sehe zwar,
welche Seite langsamer wird in meinem Lasttest.
Ich kann aber nicht erkennen, An dem, was ich
messe, weil ich kriege ja nur eine komplette Seite zurück
. War das das Erstellen dieses Inhalts? Oder das Erstellen
dieses Inhalts? Oder das Erstellen der Warenkorb-Informationen da oben rechts
auf dieser Seite, die lange gedauert hat?
Weil ich eben nicht mehr im Browser das zusammensetze,
sondern im Server, das schon passiert ist.
Wir müssen um die Zähne so fertig sein.
Ich muss noch ein bisschen fragen. Ich bin hier sofort
durch, dann lasse ich die Live-Demos da weg.
Also ein bisschen so der übliche Bröcke. Ja,
solange jetzt keine Maskenflucht einsetzt, denke ich mal,
ist es noch interessant, natürlich noch weiter.
Das ist jetzt mal so eine Splank-Auswertung
Die ich hier einfach reingemacht habe,
was wir da sehen, ist, die Requests,
die vom Client aus kommend auf dem ersten Aufsetzpunkt in unserer Infrastruktur aufschlagen,
sortiert nach dem System, was da ursprünglich mal angesprochen wird,
was sozusagen die Rahmenseite liefert, die Hauptseite, den Hauptinhalt.
Im Laufe unseres Lastests. Und dann sehe ich hier,
okay, puff, Chips, da geht es jetzt hoch.
Da haben wir genauso einen Punkt erwischt. Und in dem
Fall bei dieser Auswertung betrifft es eben nicht alle Seiten,
Sondern nur bestimmte Seiten, die von einem bestimmten Subsystem ausgeliefert werden.
Also es passt jetzt sozusagen nicht zu den anderen Reports.
Ich hatte das jetzt zwar hier auch vorbereitet,
dass wir die Live-Auswertung dann noch sehen können,
aber ich lasse das jetzt mal raus.
Das liefert mir jetzt blank. Und da kann ich dann noch
beliebig reindrillen und alles Mögliche rausziehen. Und für die Probleme,
die wir vorhin da im Lasttest gesehen haben, kommt aus dieser Auswertung raus.
Das kann ich noch so ganz kurz erklären,
dass man so ein Gefühl dafür kriegt, wo man da so hinschauen muss.
Dass sich die Laufzeitverlängerung, die mein Lasttest ausweist,
in der Protokollierung dieser Request, die hier aufschlagen sehe,
aber in der Protokollierung dieser Request, die hier abgesetzt werden, nicht.
Weshalb ich weiß, dass es irgendwie in der Komponente passiert,
die das da tut. Und dann habe ich jetzt meinen Hauptteil geliefert,
ich habe ein Problem erkannt und ich weiß,
wen muss ich ansprechen, der sich dieses Problems jetzt annehmen kann.
So, was wir außerdem noch machen, ist,
wir gucken auf diese Ressourcenauslastungsgrafen und die typischen Ressourcen sind natürlich CPU,
Platte, Rahmen-Netzwerk, hertig.
Das ist erstmal das, was an Physik
da ist
Dummerweise kommen wir zu Situationen, wo wir sehen,
wir haben irgendeinen Engpass und keiner dieser Ressourcen ist ausgelastet.
Weil es nämlich noch andere Ressourcen gibt, außer diesen physikalischen.
Eine Plattform spezifisch gibt es sowas wie Sweatpools,
wenn das Fredpool erschöpft ist, dann kann der Tomcat
keine Anfragen mehr bearbeiten, weil er kein Sweatfreie hat.
Obwohl vielleicht noch CPU da wäre und Ramda wäre und
all diese physikalischen Ressourcen noch da sind.
Garbage Collection. Es kann auch Anwendungsressourcen betreffen,
dass da irgendwas verwaltet wird und das nicht mehr funktioniert
Was wir jetzt haben, ist, wir haben unseren Jenkins-Job,
auch noch mit diesen ganzen Ressourcenauslastungsgrafen verlinkt.
Das heißt, ich kann direkt aus meinem Job sagen,
okay, jetzt zeig mir mal die Ressourcenauslastung,
der Upserver von der vertikalen XYZ zu diesem Lasttest an.
Und kann mir das anschauen. Und ich hatte ja eingangs gesagt,
wir nutzen da Graffite, das ist das,
was wirklich die Metriken sammelt und vorhält und die Grafiken produziert.
Das Grafu ist ein ganz kleiner Aufsatz,
den wir da drumherum gebaut hat, der jetzt Folgendes tut.
Wir verwalten ja in unserer Infrastruktur eine ganze Menge Systeme,
so einer Umgebung sind so zwischen 200 und 500 VMs.
Auf die verschiedenen Vertikalen, jeweils verschiedenen Instanzen, Abserver,
Datenbanken, sowas alles. Das ändert sich auch laufend.
Das kann ich also nicht statisch konfigurieren, welche Maschinen ich
mir eigentlich angucken muss, um die Upserver von XYZ zu sehen.
Wir haben Inventory, da wird das alles verwaltet und
das Grafu generiert jetzt sozusagen die richtigen Links auf diese Graffite
Grafen in Anbetracht der Kenntnis aus diesem Inhaltsverzeichnis,
welche Maschine gerade in welcher Umgebung, welche Aufgabe hat.
So, und das, was wir dann da rauskriegen,
ist sowas hier, da sehe ich jetzt dann die verschiedenen
Ressourcen und ein typisches Szenario hier habe ich den Verursache eines Performance-Buttlenecks erkannt.
Da kommt die CPU an den Anschlag und wer so mit CPU-Grafen schon mal gesehen hat,
die sind in allen Monitoren, Tools eigentlich gleich aufgebaut.
Das, was hier bei unten kommt,
ist die gute Last und das, was von oben runterfällt,
ist die schlechte, die böse Last.
Gute Last ist, wo die CPU tatsächlich Dinge tut,
die ich ihr aufgegeben habe, sie zu tun.
Also meine Anwendung, Logik berechnet. Schlechte Last ist,
wo die CPU blockiert ist durch Aktivitäten, die ich nicht haben will.
Zum Beispiel durch die Aktivität, ich warte darauf,
dass der RO zurückkommt
Und da haben wir ganz offenbar ein Problem,
dass da ganz viel Iowaite passiert und das frisst uns die
CPU weg und deshalb kann die Maschine nicht das leisten,
was sie leisten sollen. So, das ist die Ressourcensicht,
die wir jetzt in unseren Lasttest machen und ich gucke dann immer,
sieht eigentlich die Ressourcenauslastungskurve auf diesen Maschinen ungefähr synchron aus zu der Last,
die ich da drauf gegeben habe.
Also auch dort müsste ich eigentlich so linearen Anstieg sehen,
dann wäre der Sourcenverbrauch auch linear zu lassen und dann kann das auch linear skalieren,
bis ich irgendwann mal gegen die Grenzen oben stoße.
Was wir jetzt dann noch machen, ist,
diese Ergebnisse mit den Ressourcenauslastungen benutzen wir,
um ein Sizing der Umgebung zu machen.
Oh Gott, das kann man überhaupt nicht erkennen.
Sorry. Nee, ich... Ich fummle jetzt mal da
nicht dran rum. Ich erkläre es einfach. Sorry.
Also da steht ungefähr die Formel, die wir machen.
Wir machen folgendes. Wir haben irgendeine Last, die wir
produziert haben.
Wir haben
einen Ressourcenauslastung gemessen
Und wir haben eine Menge Ressourcen drin. Diese Last,
mit dem Ressourcenauslastungsgrad erreicht haben. Wir geben uns einen Ressourcenauslastungsgrad
vor, den wir in der Live-Umgebung nur sehen wollen.
Der ist typischerweise bei uns 30 Prozent. Weil wir
müssen ja den Ausfall der halben Umgebung des Einrechtenzentrums verkraften.
Und dann wollen wir außerdem noch nicht am Ende sein,
am Anschlag. Also wir haben den Ausfallbeserbe unten eine Lastreserve,
die dazu führt, dass wir nur 30 Prozent Ressourcenauslastung haben wollen.
Und dann kann man so das System linie askaliert,
einfach aus dem, was man an Ressourcen und Last,
die man erreicht hat und Ressourcen, Auslastungsgrad,
die man gesehen hat, ausrechnen,
wie viele Ressourcen muss man eigentlich reinstopfen,
um dann bei der Live-Last mit dem gewünschten Ressourcenauslastungsgrad ungefähr rauszukommen.
Und das ist jetzt dann wiederum die Basis,
um diese ganze Live-Umgebung, das Thaising dafür zu machen.
Jo, und das heißt, es hilft auch sozusagen proaktiv,
die Live-Umgebung, die da neu aufgebaut wird, richtig zu zizen.
Jo, und jetzt sind wir am Ende,
also wir machen jetzt seit über zwölf Monaten kontinuierlich jeden Tag,
lass es.
Wir haben sechs Zielumgebungen, davon drei,
die wir für Lasttest nutzen
Wir haben jeweils dazwischen 150 und 150 VMs, die in
so einer Umgebung drinstecken, 50, vor allem ist das Lastgeneratoren.
Wir machen fünf bis zehn Lasttestläufe am Tag. Ein so ein Last-Testlauf bringt im Normalfall,
wenn wenig Fehler produziert werden, fünf bis zehn Gigabyte-Daten,
wenn viele Fehler produziert werden im Lasttestlauf,
dann werden auch viele Fehler mit protokolliert,
was man da im Browser dann sieht.
Dann machen wir auch schon mal 100 Gigabyte in einem Lasttestlauf
an Ergebnisdaten. Pro VM werden bei uns in Glaffight
über 100 Metriken minütlich mit protokolliert
Da kann man sich jetzt schon ausrechnen,
wie viele Metriken wir da generell in Greiffeld reinschieben.
Das sind inzwischen drei Greiffeld-Server, die das machen.
Ist sehr empfehlenswert. Sehr stabil, sehr zuverlässig.
Grafen sind relativ schnell da. In den Lasttests erzeugen wir
ungefähr 100 Gigabyte Logvolumen, die danach splank reingepumpt werden.
Steiger kostet ja nichts mehr heutzutage. Anderswo nicht, bei
uns schon. Und es gab das jetzt drei Meilensteine,
es gab so einen Mitterschalter-Shop, Closed Alpha, Live Beta.
Und wir haben jeweils vorher die Ziele erreicht,
die wir uns für diesen Meilenstein vorgenommen hatten.
Und es war jeweils ein, deutlich mehr, als wir
in diesem Meilenstein tatsächlich erwartet haben an Last. Das heißt,
obwohl ich das aus vielen Systemen in der Vergangenheit so kenne,
dass man dann Livegangstermin dann doch unsicher war,
wird es da hinhauen und wird man das wirklich abkönnen,
weil man geht das erste Mal so richtig jetzt nach draußen.
Das war in Sachen Last, jedes Mal sehr entspannt,
auch immer immer wunderbar funktioniert.
Also der ganze Aufwand hat sich insofern rentiert.
Okay. Ja, Frage
Wie viele Leute arbeiten? In diesem Team, das das macht, zwei. Einer,
der all diese Lastis baut und am Laufen hält und ich,
der sie permanent auswertet und zu den Teams renne,
wenn ich was entdeckt habe.
Das geht nur deshalb so einfach, weil wir
mit simulierten Browsern arbeiten können. Das heißt,
wir können uns eigentlich auch bei den funktionalen Tests bedienen,
können da was abkupfern, weil wir testen auch die Funktionalität über Selinium-Tests ab.
Wir haben Page-Objekte, die wir weiterverwenden können.
Wir brauchen da nicht ständig nachbauen. Wir haben das
einmal gebaut
Das läuft jetzt einfach. Wir machen nichts anderes nebenbei.
Naja, ich mache schon noch ein bisschen nebenbei.
Aber mein Kollege, der macht wirklich nur das.
Es gibt jetzt dann auch noch Spezialformen von Lasttests,
die wir da auch noch machen, aber lasse ich jetzt mal aus.
Wenn ich deswegen gesagt habe,
wie ihr die URF zusammenstellt für den Request,
aber das sind die Hälfte,
weil wir müssen auch jetzt über die Content-Bereichsteuerung getestet werden,
damit ihr
ein realistisches Ergebnis habt
Zwölf alten System, du hast es vielleicht letztendlich,
müsstet ihr eure Verleihssysteme konsistent umkopieren.
Da hatten wir schon so Sachen, die wir kennen,
das live daten sollten, die wir anmissierten.
Zettel haben die geschickt. Wir haben zu einer Platte getan
. Und die kommen ja auch zu vorgelagerten Systemen.
Eine Testo-Umgebung hängt an dem Preis. Ich habe da jetzt
gerade die gleichen Daten, die jetzt kriegen,
dieselben Werke und das, was ein Artikel jetzt ausverkauft ist,
das Neujahr kaum rot und nicht runden.
Das heißt, der ganze Produktgestatt ist leicht beentisch,
obwohl er nicht abgezogen wird,
so halten wir einfach auf die seltenen Werke
von den Vorsystemen
So. Dann sieht es so aus,
dass wir nicht live Kunden arbeiten in den Testsystemen,
in den Testkunden, sondern auf einmal die kühlen letzten Autos
ist hier mit dem Mann oder den Tests, der auch dann investiert worden.
Das ist der Regierungsleute gibt, jedes Mal,
wenn man die verschiedenen Eckernsysteme einen neuen Leib abzudrücken, erfüllt wurden,
die Leibfahrt rausgeschmissen werden und dann hätten wir wieder ein paar tausend Testkunden da drin,
die mit diesen Kunden und ich hatte auch so die Testkunden,
werden wir da zufällig ausreichen.
Das ist eine Einstellung, das ist extra.
Andere Castro-Service, da gehe ich mit
Dass man in dem Markt nicht braucht,
bekunden für die Umkunft sowieso,
da muss man eine Eigenschaften haben und die verwaltet alle diese Testkunden,
weiß, welcher Testkunden in welcher Umgebung gerade so fehlt,
ist ein anderes, da ich die so und Empfehlungen ziehe,
da regt es sich ab, sind aber dann nicht personalisiert,
also wir machen es schon öffentlich zur Empfehlung,
aber das wird dann personalisiert für unsere Testkunden, also ja,
das ist meiste jetzt dort, eigentlich schon was magisches.
Das sind ja gar nicht so große Datenmenschen im Live-System,
viertel, Ja, also wir müssen ja die ganzen Wahlen,
das ist alles nicht so ein Leidenssystem abziehen,
weil wir produzieren einfach die eigenen.
Die bleibt zu dem natürlich so einen riesigen Garten,
der auch nochmal eine Auswirkung auf den Bestens haben könnte.
Wir sind denen auch noch nicht lustig. Dorf,
Produktdaten, Stand, Mitarbeiter haben sie dazu. Also,
Wiedermeister kommt schon zusammen, aber es sind jetzt keine Tickenarbeitsanlagen.
Ja. Du hast vorhin gesagt,
dass die Testläufe so ein bisschen passig zusammengestellt haben
Ja. Habt ihr mal geguckt, wie viel das so...
Also du zweimal die selbe Fischlappen lässt,
auf die Säle derselben Softwareversionen, mit denselben Testdaten,
die sehr weichen zeigen, fangen ab.
Und bedient sich das oder ist das? Also die Gruppen,
die ich da vorher gezeigt habe, die sehen ziemlich frei aus.
Also praktisch beiden Einfluss, also ich nicht. Also,
weil wir ja da auch in so einem Lasttestlauf machen,
wir zwischen gute Millionen Feature-Patches.
Animiert sich schreiend aus. Und ich sehe das immer
sehr gut,
ob das gut funktioniert
Weil wir machen ja einen Titel, unser lasst das heute.
Also machen wir euch am Samstag, Sonntag oder Sonntag ein,
Entwickler entwickeln in dieser Zeit nicht ganz so viel.
Also quasi keine Änderung des Systems.
Wir machen jetzt dreimal die Denchlaufer und identische Zielsystem,
weil es sich nicht geändert hat und die,
was das erlebliche von Waffenslobbern übergleich.
Im Detail weichen sie natürlich schon ein bisschen ab,
aber das tritt Standard.
Wo speichert ihr diese ganzen gigantischen Testdaten,
die Ergebnisdaten
Naja, auf. Gut,
dann haben wir halt ein Plausi zu sagen,
Freiburg Cloud aufgebaut, in dem das alles gut läuft.
Eine Rechtszentrumsbetreiber. Gut, ich glaube,
wir haben jetzt da in der Preise Cloud 27 Terabyte.
Das ist nicht wie die alles auch gar nicht so gut.
Weil wir erinnern viel von diesem Testdatenmengen,
da komme ich nicht das, was vor vier Wochen war.
Ich habe mir die Mast-Test-Trikot eingeholt. Weil ich was ausgekommen ist,
der Teilanalyse von dem, was da vor vier Wochen passiert ist,
mache ich eine E-Mail.
Das heißt,
die Dinger finden dann aus
Uns bleiben, war ich der Plattenplatz gerade,
war so weit, dass wir in letzter Tagesfrage zahlen.
Das heißt, ich kann am Montag, boah, es war Freitag analysieren.
Weil es ja dann die Zeichen schon wieder neue Erkenntnisse gibt,
ist, dass da unwieso Altersschauen entweder zu ermöglichen ist,
immer noch da,
da kann ich auch die neuen Sachen draufgeben und das analysieren und das Ding ist weg,
dann hoffen alle, dass es auch weg bleibt.
Ja, es ist immer mal wieder zeigt,
man weiß, man war tatsächlich so ein ganz böses,
interpretiertes Problem, das schon ab und zu mal auftaucht,
dann muss man irgendwie geziert was dafür bauen,
was nur diese Probleme sind
Wenn ihr nur zwei Leute seid. Das heißt,
wenn ihr Urlaub macht, macht das niemand oder macht den Böller.
Dann macht er sich keinen Urlaub. Also es gibt auch bedeutet,
dass sich die breitheitliche Aufgabenstellung für den alten Shop kümmert.
Insofern können wir da auch Blows of Tablets. Was macht
ihr oder was passiert, wenn der Shop jetzt live ist?
Ich meine, die Entwicklung geht sich wahrscheinlich weiter.
Aber die Entwicklung geht weiter. Auch gut gegeben,
eine Iskalt, habe ich eine neue Scheiße,
Dann sitzen sie wieder falsch gemacht zu haben.
Insofern ist das einfach weiterlaufen. Also praktisch im gleichen Schema,
auch mit der gleichen Identität, Martin im neuen Chat.
Also die Intensität wird schon ein wenig atmen,
weil die Wahrscheinlichkeit, dass noch mal ganz unbeliegende Erinnerungen gemacht werden,
die ganz grundlegend Probleme auch als aufwerfen, die wird genug werden.
Ohne Interfern wird man viel häufiger den Zustand haben,
dass man sagt, der Englische selbst bin ich vorne,
brauche ich gar nicht weiter interviewt zu machen.
Ich musste hier was machen. Die ersten Ergebnisse sofort,
dass es eigentlich den Schema so,
da wird der Aufwand schon de facto sein
Wie funktioniert das erstellt, weil das würdest du mir jetzt
nicht vorstellen. Genauso kann man das mit Ferlinien,
dem Funktionaltest kennt und das XRT-Tool hat dann die Möglichkeit zu sagen,
diese Transaktionen, die ich da definiert habe,
davon bin ich sehr bis zu 500 Leute generieren, die das tun.
Und zwar mit folgendem Lastprofil eben und die ganze Zeit der Konstante Last.
Ich kann da sogar eine richtige Lastkurve vornehmen,
Göttin Ditt, dass die live gelastlosen Kurve nachstellen.
Und bittet sie ja mit Singtime Starphone und sind halt zwischen den Steps und zwischen Transaktionseiner durchgelaufen,
die nächsten Transaktionen wird gemacht und sie sollen in Gita haben, das sind einfach Konfigurationsdateien.
Da haben wir ein Set von vorbereiteten Konfigurationsdateien, das ist unsere Pressetory. Irgendwann gibt es ungefähr so 30 verschiedene Lasttest-Jobs in unserem Jenkins,
die jeweils zum gewissen Set von solchen Einstellungen machen,
da können wir uns dann einfach die verschiedenen Konfigurationen zusammen probieren und sagen,
was ist so mein Minimum, was,
wo ruft aufs Maximum Last, Bücher machen, ich maximal,
wie soll das halten, wenn es wirklich JavaScript hier sein,
ist das ein Test, Mitbestimmung oder ohne,
man ist vielleicht über aktuelle Bestellung,
den letzten Schritt sparen und so.
So gibt es sozusagen so ein paar Konfirmations-Bausteine. Dann haben wir
so inzwischen acht oder zehn Konfirmationsdateien probiert man sich schnell zusammen
und damit hat man sein Set für so ein Lastdissen auf,
hat ja genau das geschafft.
Der wird dann einfach nur in dem Jenkin-Job vertratet und
dann ist die Checkles benutzt mir quasi als irische Jobssteuerung.
Da kann jeder auf den Knopf drücken. Und auch jemand,
der keine Ahnung verlasst ist, hat,
was die eigentlich tun, weil der jetzt nur überprüft,
wie der nicht funktionale Anforderungen erfüllt werden,
also auch ein Milchstaben der Forens in der Last funktioniert
Er sagt, er braucht es von uns leisten und sagen,
okay, was brauchst du für Last,
wo kommst du richtig im Job hin, sagen,
da kannst du auf den Kopf drücken,
dann kannst du testen, was bei dir gestanden ist.
Das sind wir auch, ob wir die jüde Bücher jetzt wieder schauen können.
Noch wichtiger. Wir haben noch genug damit zu tun.
Die Last, die das System können sollte, zu können.
Bevor wir uns an den Punkt drücken können,
man kann es dann auch die anderen Sachen.
Was es gibt, es gibt Security-mäßig auch noch das,
so eine Denial-of-Service-Attacke, bestimmte Ehrenzugangs gemacht. Ist aber separat,
abonnieren nicht. Da geht es schon um das zu.
Habt ihr bei euren Überlegungen auch so gut da gedacht,
dass es mir da eigentlich eine Flugfrage,
ob das System auf große Last-Leveln in irgendeiner Sucht reagiert.
Das war schon so, wenn ein sehr hoher Last-Peak da ist,
ist dann die Empfehlung, die ich immer ausgesprochen bin,
oder das Ressourcenintensiv ist ja ähnliches.
Ja, sozusagen, Entschuldigung. Ja, aus der,
dieses easy Flugsport bekommen, von Ibanisch gesprochen,
da kann man Timer zu konfrontieren,
man kann auch konfrontieren,
was er tun soll und wenn nicht das eben nicht kommt
Für die Empfehlung gibt es da eine relativ schöne Möglichkeit,
das ganze Grace Mood. Und zwar können wir dann sagen,
hey, das ist eine cashbare Antwort,
aber die ist dummerweise mulsig und ungültig. Das heißt,
bei der nächsten Anfrage, die ist für solche Empfehlungen kommen,
wieder der Empfehlungskonfess an die Server geschickt werden.
Und da haben wir einen relativ kurzen Timeout dafür,
wenn der zuschlägt, sagt der war ein stummer,
leise haben wir jetzt keine Antwort bekommen,
aber ich habe noch eine veraltete Antwort bekommen.
Und das haben wir noch nicht richtig ausgereizt.
Da gibt es schon
noch einiges zu tun
Du schmeißt mir rum, was da,
dass ich jetzt für all diese Seitenstandteile zu überlege,
kann man dann zum Facebook arbeiten, schweimen wir die vier Sachen aus,
schnäumen wir einfach eine Leeresfeldausfall, die Produktliste ist ja da,
wenn wir den Zusatz nicht traut, für diesen Stunden,
dann gibt es schon etliche Möglichkeiten,
die man scheuen kann,
diese konzeptionelle Angedachte oder so längst beschreiben muss.
Ja,
ich auch