Performance Testing 101 [DE]

This is a presentation in German I gave in June 2017 on the Web Performance Meetup in Hamburg, Germany.

Abstract:

Performance Testing 101: HTTP-basierte Systeme

HTTP-basierte Systeme sind allgegenwärtig: Webseiten, Single-Page Web Applications (SPA), APIs für Mobile Apps, Spiele, APIs für Tracking und Monitoring – um nur einige zu nennen. Das heißt allerdings auch: Laufzeit-Umgebungen ebenso wie Software-Stacks werden zunehmend komplexer und gerade in punkto Performance wird es immer schwerer, wenn nicht gar unmöglich, Eigenschaften und Verhalten vorherzusagen.

Performance Tests sind ein wichtiges Instrument, um hier Abhilfe zu schaffen – sie tragen dazu bei, ein System und dessen Laufzeitumgebung zu verstehen und so die Prognosesicherheit entscheidend zu erhöhen. Zugleich sind sie ein alles andere als triviales Unterfangen und in der überwiegenden Zahl der DevOps Teams (noch) nicht ausreichend verankert.

In diesem Talk wird daher ein Überblick über Problemstellungen und Methodiken des Performance Testing gegeben und aufgezeigt, wie ein pragmatischer Einstieg in das Themengebiet gefunden werden kann. An konkreten Fallbeispielen wird gezeigt, wie Tests geplant, aufgesetzt, durchgeführt und ausgewertet werden können.

Transcript

1. Performance Testing 101:
 HTTP-basierte Systeme Sebastian Cohnen – @tisba – 2017
2. EHLO hamwebperf • Sebastian Cohnen (@tisba) • 7+ Jahre Beratung und Entwicklung • Fokus auf Performance und Architektur • Gründer & CTO StormForger.com
3. Einführung
4. Einführung • Performance (vs Skalierbarkeit) • Performance Testing • Wie muss man Performance Testing verstehen?
5. Performance
6. Performance • Fähigkeit eines Systems eine Aufgabe
 in einer definierten Dimension zu erledigen • = Effizienz eines Systems • "1 Server schafft 250 rps mit p99 50ms"
7. Skalierbarkeit
8. ≠ Performance Skalierbarkeit
9. Skalierbarkeit • Effektivität mit der die Kapazität durch Ressourcen gesteigert werden kann
 
 
 "1 Server schafft 250 rps mit p99 50ms"
 
 und
 
 "10 Server schaffen 2500 rps mit p99 50ms"
10. Woran erkenne ich, dass ich ein Performance-Problem habe? http://www.slideshare.net/jboner/scalability-availability-stability-patterns/15-How_do_I_know_if
11. Wenn dein System langsam für
 einen einzelnen Benutzer ist.
12. Woran erkenne ich, dass ich ein Skalierungs-Problem habe? http://www.slideshare.net/jboner/scalability-availability-stability-patterns/15-How_do_I_know_if
13. Wenn dein System schnell für einzelne Benutzer ist, aber langsam unter Last. https://www.flickr.com/photos/jamespaullong/with/714577655/
14. Performance ⚡ Skalierbarkeit – Robert Johnson https://www.facebook.com/note.php?note_id=409881258919 "…Efficiency projects rarely give you enough improvement to have a big effect on scaling." "Scaling usually hurts efficiency…"
15. Warum ist das relevant? Ohne zu wissen, ob man an einem Performance oder Skalierungsproblem arbeitet, läuft man Gefahr in eine falsche Richtung zu laufen.
16. Performance Testing
17. –Wikipedia “In software engineering, performance testing is in general,
 a testing practice performed to determine how a system performs
 in terms of responsiveness and stability
 under a particular workload.” https://en.wikipedia.org/wiki/Software_performance_testing
18. Performance Tests • System anregen mit einer definierten Last • Verhalten beobachten • Eigenschaften verifizieren • Verhalten verstehen
19. Performance Tests • Sammlung nicht-funktionaler Testmethoden • Nicht ganz trennscharf zu definieren • Unterschiedliche Ziele und Perspektiven Load Testing Stress Testing Spike Testing Soak Testing Endurance Testing Resilience Testing Configuration Testing Scalability Testing
20. Performance Tests? • Nicht nur für die Großen™! • Nicht nur zum Testen von Releases • Evaluierung von… • Technologie, • Proof of Concepts, • Troubleshooting und Debugging
21. Wenig Traffic
 ≠
 Keine Performance Probleme
22. Motivation
23. Wir haben 100 Personen gefragt… Warum Performance Testing?
24. Warum Performance Testing? • "Kundenanforderungen verstehen" • "Eigene Grenzen kennenlernen, Probleme antizipieren" • Qualitätssicherung • Risikobewertung • Konfigurationen Testen • Bugs, Sizing, Kosten Optimierung
25. Warum kein Performance Testing? • "Fix it, when it breaks" • Premature Optimization • "Angst vor viel Aufwand" • "Zu wenig Erfahrung"
26. Und ihr?
27. Performance Testing? {Time,Availability} == Money
28. Warum? • Komplexität der Systeme • daher Verständnis notwendig von… • eigener Anwendung • System & Softwarearchitektur • Cloud/Laufzeit-Umgebung –Physik “Komplexe Systeme sind Systeme mit hoher Wechselwirkung.”
29. Wie?
30. Herausforderungen • (in der Regel) kein Tooling-Problem • organisatorische Hürden • Monitoring der eigenen Systeme!1!!11 • Anfangen
31. Fallbeispiel: Online Shop
32. Ziele & Anforderungen definieren • Ziele vorher definieren (Warum testen wir?) • Anforderungen immer von der Fachseite her denken und definieren
33. Ziele & Anforderungen definieren • Ziel: • "Black Friday überstehen" • Anforderungen: • Seite ausgeliefert in unter 2s • X Visits/Stunde, Y min Verweildauer • 100k Warenkörbe, 10k Checkouts pro Stunde, …
34. Womit anfangen zu testen? • System Under Test (SUT) definieren • richtigen Scope finden • Perimeter/Ende-zu-Ende Tests • Komponenten/Service Tests
35. Scoping / System Under Test • Testing von oben via FE oder "seitlich" gegen einzelne Services • Für Fachseite sind in der Regel nur integrative Tests interessant • Tests einzelner Services zwecks Trouble Shooting (technische Perspektive)
36. Wie kommt man an Anforderungen/SLA? • (sofern nicht klar definiert…) • fachliche Ziele aufnehmen • Annahmen zu Nicht-funktionale Anforderungen (NFA) treffen • Hilfestellung via • "Baseline" Performance Tests • Performance Budget • Sanity Checks machen!
37. Performance Budget Browser Firewall Load Balancer Webserver App Server Service A Service B … FACT-Finder FACT-Finder FACT-Finder MySQL MySQL MySQL ☁ ☁ MySQL MySQL Cache ……
38. Wie anfangen? • Pragmatismus über Perfektion • von … zu … • simpel zu komplex(er), in kleinen Schritten • punktuell über regelmäßig zu kontinuierlich • Annahmen herleiten, festlegen und dokumentieren • von der Fachseite her an Probleme und Anforderungen herangehen
39. Ziel: Iterativ vorgehen! • Design • Implementierung • Messen und Validieren • Wiederholen!
40. Sebastian Cohnen
 support@stormforger.com @tisba