SlideShare ist ein Scribd-Unternehmen logo

11.performance meetup lasttests

Uwe Bessle
Uwe Bessle
Uwe BessleIT-Consultant um iteratec GmbH

Präsentation zum Thema Lasttests auf dem 11. Performance Meetup in Hamburg

11.performance meetup lasttests

1 von 66
Downloaden Sie, um offline zu lesen
11. PerformanceMeetup
28. Mai 2013
Uwe.Bessle@iteratec.de
Effektiver Einsatz von Lasttests zur
Optimierung der Skalierbarkeit von
Web-Sites
© iteratec
2
Agenda
 Erschlagen vom eigenen Erfolg
 Beispiele aus der jüngeren Vergangenheit
 Auch die Cloud ist kein Allheilmittel
 Fahrplan zu entspannten Live-Gängen
 Erfahrungen und Ergebnisse in der Praxis
© iteratec
3
Vom eigenen Erfolg erschlagen
Telekom Mobilfunkseite durch iPhone5 Andrang
 Quelle: http://www.heise.de/mac-and-i/meldung/iPhone-Vorbestellung-ueberlastet-Telekom-1708303.html
© iteratec
4
Vom eigenen Erfolg erschlagen
DaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen
 Quelle: http://de.dawanda.com/topic/2169/10130642
© iteratec
5
Vom eigenen Erfolg erschlagen
GovData: www.daten-deutschland.de vom Start weg überlastet
 Quelle: http://www.computerwoche.de/a/datenportal-der-bundesregierung-startet-holprig,2533210
© iteratec
6
Agenda
 Erschlagen vom eigenen Erfolg
 Beispiele aus der jüngeren Vergangenheit
 Auch die Cloud ist kein Allheilmittel
 Fahrplan zu entspannten Live-Gängen
 Erfahrungen und Ergebnisse in der Praxis
Anzeige

Recomendados

Open Source BPM - iteratec Architekturtag
Open Source BPM - iteratec ArchitekturtagOpen Source BPM - iteratec Architekturtag
Open Source BPM - iteratec Architekturtagcamunda services GmbH
 
iDocIt - Ein Assistent zur API-Dokumentation
iDocIt - Ein Assistent zur API-DokumentationiDocIt - Ein Assistent zur API-Dokumentation
iDocIt - Ein Assistent zur API-DokumentationJan Christian Krause
 
DevCon-2013-PerformanceSkalierbarkeit_UweBessle
DevCon-2013-PerformanceSkalierbarkeit_UweBessleDevCon-2013-PerformanceSkalierbarkeit_UweBessle
DevCon-2013-PerformanceSkalierbarkeit_UweBessleUwe Bessle
 
Everything-as-code: DevOps und Continuous Delivery aus Sicht des Entwicklers.
Everything-as-code: DevOps und Continuous Delivery aus Sicht des Entwicklers.Everything-as-code: DevOps und Continuous Delivery aus Sicht des Entwicklers.
Everything-as-code: DevOps und Continuous Delivery aus Sicht des Entwicklers.QAware GmbH
 
Gut dokumentiert ist halb gesichert
Gut dokumentiert ist halb gesichertGut dokumentiert ist halb gesichert
Gut dokumentiert ist halb gesichertJan Christian Krause
 
DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?
DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?
DWX 2016 - Monitoring 2.0 - Monitoring 2.0: Alles im Lot?Marc Müller
 

Más contenido relacionado

Ähnlich wie 11.performance meetup lasttests

DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes QAware GmbH
 
#SUGDE Sitecore Gesundheit
#SUGDE Sitecore Gesundheit #SUGDE Sitecore Gesundheit
#SUGDE Sitecore Gesundheit chriswoj
 
95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemacht
95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemacht95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemacht
95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemachtNico Orschel
 
Karlsruher Entwicklertag 2016 - Monitoring 2.0: Alles im Lot?
Karlsruher Entwicklertag 2016 - Monitoring 2.0: Alles im Lot?Karlsruher Entwicklertag 2016 - Monitoring 2.0: Alles im Lot?
Karlsruher Entwicklertag 2016 - Monitoring 2.0: Alles im Lot?Marc Müller
 
AdvancedTdd
AdvancedTddAdvancedTdd
AdvancedTddjlink
 
Streaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der WahlStreaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der WahlMatthias Niehoff
 
Nagios Conference 2006 | SAP Monitoring I by Michael Kienle
Nagios Conference 2006 |  SAP Monitoring I by Michael KienleNagios Conference 2006 |  SAP Monitoring I by Michael Kienle
Nagios Conference 2006 | SAP Monitoring I by Michael KienleNETWAYS
 
Automatisierter Software-Test unter Java
Automatisierter Software-Test unter JavaAutomatisierter Software-Test unter Java
Automatisierter Software-Test unter JavaGFU Cyrus AG
 
ONE Konferenz: Von der Idee zur App
ONE Konferenz: Von der Idee zur AppONE Konferenz: Von der Idee zur App
ONE Konferenz: Von der Idee zur AppNetcetera
 
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...NETWAYS
 
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse QAware GmbH
 
BizDataX Testdatenmanagement Konzepte
BizDataX Testdatenmanagement KonzepteBizDataX Testdatenmanagement Konzepte
BizDataX Testdatenmanagement KonzepteDragan Kinkela
 
Pink Monitoring oder wie Prometheus Licht ins Dunkel der Container bringt 
Pink Monitoring oder wie Prometheus Licht ins Dunkel der Container bringt Pink Monitoring oder wie Prometheus Licht ins Dunkel der Container bringt 
Pink Monitoring oder wie Prometheus Licht ins Dunkel der Container bringt Klaus Bild
 
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen SystemlandschafteneCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen SystemlandschaftenChristoph Menke
 
Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten...
Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten...Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten...
Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten...Markus Harrer
 
Der Status Quo des Chaos Engineerings
Der Status Quo des Chaos EngineeringsDer Status Quo des Chaos Engineerings
Der Status Quo des Chaos EngineeringsQAware GmbH
 

Ähnlich wie 11.performance meetup lasttests (20)

DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
 
#SUGDE Sitecore Gesundheit
#SUGDE Sitecore Gesundheit #SUGDE Sitecore Gesundheit
#SUGDE Sitecore Gesundheit
 
95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemacht
95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemacht95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemacht
95 Prozent brauchen es, 5 Prozent machen es: Load Testing mit VS leicht gemacht
 
Karlsruher Entwicklertag 2016 - Monitoring 2.0: Alles im Lot?
Karlsruher Entwicklertag 2016 - Monitoring 2.0: Alles im Lot?Karlsruher Entwicklertag 2016 - Monitoring 2.0: Alles im Lot?
Karlsruher Entwicklertag 2016 - Monitoring 2.0: Alles im Lot?
 
AdvancedTdd
AdvancedTddAdvancedTdd
AdvancedTdd
 
Streaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der WahlStreaming Plattformen und die Qual der Wahl
Streaming Plattformen und die Qual der Wahl
 
Nagios Conference 2006 | SAP Monitoring I by Michael Kienle
Nagios Conference 2006 |  SAP Monitoring I by Michael KienleNagios Conference 2006 |  SAP Monitoring I by Michael Kienle
Nagios Conference 2006 | SAP Monitoring I by Michael Kienle
 
Automatisierter Software-Test unter Java
Automatisierter Software-Test unter JavaAutomatisierter Software-Test unter Java
Automatisierter Software-Test unter Java
 
SpiraTeam im Überblick
SpiraTeam im ÜberblickSpiraTeam im Überblick
SpiraTeam im Überblick
 
ONE Konferenz: Von der Idee zur App
ONE Konferenz: Von der Idee zur AppONE Konferenz: Von der Idee zur App
ONE Konferenz: Von der Idee zur App
 
Xidra 2016 DevOps
Xidra 2016 DevOpsXidra 2016 DevOps
Xidra 2016 DevOps
 
Definition of Ready
Definition of ReadyDefinition of Ready
Definition of Ready
 
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
OSMC 2013 | Enterprise Platforms Monitoring at s IT Solutions AT by Johannes ...
 
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
Observability: Der Schlüssel für Threat Detection, Mitigation und Analyse
 
BizDataX Testdatenmanagement Konzepte
BizDataX Testdatenmanagement KonzepteBizDataX Testdatenmanagement Konzepte
BizDataX Testdatenmanagement Konzepte
 
Pink Monitoring oder wie Prometheus Licht ins Dunkel der Container bringt 
Pink Monitoring oder wie Prometheus Licht ins Dunkel der Container bringt Pink Monitoring oder wie Prometheus Licht ins Dunkel der Container bringt 
Pink Monitoring oder wie Prometheus Licht ins Dunkel der Container bringt 
 
JavaFX Real-World Apps
JavaFX Real-World AppsJavaFX Real-World Apps
JavaFX Real-World Apps
 
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen SystemlandschafteneCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
 
Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten...
Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten...Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten...
Einsatzmöglichkeiten der automatisierten Analyse von Artefakten und Metadaten...
 
Der Status Quo des Chaos Engineerings
Der Status Quo des Chaos EngineeringsDer Status Quo des Chaos Engineerings
Der Status Quo des Chaos Engineerings
 

11.performance meetup lasttests

  • 1. 11. PerformanceMeetup 28. Mai 2013 Uwe.Bessle@iteratec.de Effektiver Einsatz von Lasttests zur Optimierung der Skalierbarkeit von Web-Sites
  • 2. © iteratec 2 Agenda  Erschlagen vom eigenen Erfolg  Beispiele aus der jüngeren Vergangenheit  Auch die Cloud ist kein Allheilmittel  Fahrplan zu entspannten Live-Gängen  Erfahrungen und Ergebnisse in der Praxis
  • 3. © iteratec 3 Vom eigenen Erfolg erschlagen Telekom Mobilfunkseite durch iPhone5 Andrang  Quelle: http://www.heise.de/mac-and-i/meldung/iPhone-Vorbestellung-ueberlastet-Telekom-1708303.html
  • 4. © iteratec 4 Vom eigenen Erfolg erschlagen DaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen  Quelle: http://de.dawanda.com/topic/2169/10130642
  • 5. © iteratec 5 Vom eigenen Erfolg erschlagen GovData: www.daten-deutschland.de vom Start weg überlastet  Quelle: http://www.computerwoche.de/a/datenportal-der-bundesregierung-startet-holprig,2533210
  • 6. © iteratec 6 Agenda  Erschlagen vom eigenen Erfolg  Beispiele aus der jüngeren Vergangenheit  Auch die Cloud ist kein Allheilmittel  Fahrplan zu entspannten Live-Gängen  Erfahrungen und Ergebnisse in der Praxis
  • 7. © iteratec 7 Erschlagen vom eigenen Erfolg  Grundidee:  Einsatz von Standardkomponenten zur Lastverteilung (Load-Balancer)  + horizontale Skalierbarkeit der Anwendungskomponenten  + dynamisches Buchen zusätzlicher Ressourcen in der Cloud  = Lastprobleme einfach gelöst Wozu brauche ich Lasttests, ich habe doch die Cloud ? Internet Firewall LoadBalancer Web- Server Web- Server App- Server App- Server LoadBalancer App- Server Datenbank Auth (LDAP) Cache
  • 8. © iteratec 8 Erschlagen vom eigenen Erfolg Theory meets Reality  typische Bottlenecks: alles was zentral ist  RZ-Anbindung,  Firewall,  zentraler Load-Balancer,  zentraler Cache,  zentrale Datenbank,  zentraler Authentication Server (LDAP)  typisches Problem: Implementierungsfehler hebeln Skalierbarkeit aus Wozu brauche ich Lasttests, ich habe doch die Cloud ? Internet Firewall LoadBalancer Web- Server Web- Server App- Server App- Server LoadBalancer App- Server Datenbank Auth (LDAP) Cache
  • 9. © iteratec 9 Agenda  Erschlagen vom eigenen Erfolg  Fahrplan zu entspannten Live-Gängen  Definition von Lastanforderungen  Lasttests zur Überprüfung der Lastanforderungen  Auswahl der passenden Tools  Auswertung von Lasttests  Sizing der Systeme auf Basis von Lasttestergebnissen  Erfahrungen und Ergebnisse in der Praxis
  • 10. © iteratec 10 Fachliche Anforderung Technische Entsprechung Betrachtungs- Unterschied Anzahl Besucher #User unangemeldete Besucher Visits pro Monat #Session/h Betrachtungs-Zeitraum, Session-Timeout, Bot-Session PageView bzw. PageImpression pro Tag Hit/s Betrachtungs-Zeitraum, statische Ressourcen, AJAX-Requests, Tracking-Requests, API-Calls Definition von Lastanforderungen Typische Kennzahlen
  • 11. © iteratec 11  Generelle Empfehlung: Ausrichtung an den Business- Anforderungen  Business-Kennzahlen als Basis für die Definition der Lastanforderungen verwenden  Aber: Abweichungen zur technischen Sicht berücksichtigen  Die Server müssen die technisch ankommende Last verkraften  Richtigen Betrachtungszeitraum wählen  technisch motivierte Lastkomponenten berücksichtigen  Bot-Requests  Statische Ressourcen  AJAX-Calls  Tracking-Requests Definition von Lastanforderungen Woran ausrichten
  • 12. © iteratec 12 Definition von Lastanforderungen Betrachtungs-Zeitraum : Typische Tageskurve
  • 13. © iteratec 13 Definition von Lastanforderungen Betrachtungs-Zeitraum : Monatsverlauf relevante Kennzahl für Businessplan maßgebliches Ziel für Lasttest
  • 14. © iteratec 14  Statische Ressourcen  bis zu 100 Bilder, Javascript- und CSS-Dateien pro Seitenaufruf Definition von Lastanforderungen Übersehene Anforderungsbestandteile : Statische Ressourcen MIME Type Requests▼ image 80 js 16 html 12 css 10 other 6 text 2 flash 0  Lösungen  auf CDN auslagern  auf eigene Cookie-less Domain auslagern  im Lasttest mit berücksichtigen (Last mit generieren)
  • 15. © iteratec 15  Woher kommen zusätzliche Requests?  Google  Microsoft Bing  diverse andere Suchmaschinen  automatisiertes Verfügbarkeits-Monitoring  automatisiertes Performance-Monitoring  Benchmarking der Wettbewerber  Verlinkungen in sozialen Netzwerken  ...  Bots verursachen  50% aller Sessions  10% aller Seitenaufrufe  1-click Sessions (Bot setzt keinen Cookie) Definition von Lastanforderungen Übersehene Anforderungsbestandteile : Bot-Requests
  • 16. © iteratec 16 Definition von Lastanforderungen Abgestuftes Vorgehen mit mehreren Meilensteinen
  • 17. © iteratec 17  Woher kommen konkrete Anforderungen ? 1. Ablösung Altsystem: Zahlen zur Nutzung des Altsystem  Web-Tracking (fachliche Kennzahlen) !  Monitoring (technische Kennzahlen) Definition von Lastanforderungen Quellen für Anforderungen
  • 18. © iteratec 18  Seitenverteilung aus dem Web-Tracking Definition von Lastanforderungen Quellen für Anforderungen
  • 19. © iteratec 19  Woher kommen konkrete Anforderungen ? 1. Ablösung Altsystem: Zahlen zur Nutzung des Altsystem  Web-Tracking (fachliche Kennzahlen) !  Monitoring (technische Kennzahlen) 2. neue Anwendungen:  Business Case  Benchmarking (Wettbewerber) 3. Interviews (Stakeholder: Fachabteilung, Betrieb, ...)  haben oft nur allgemeine Ziele und wenig konkrete Vorstellungen Definition von Lastanforderungen Quellen für Anforderungen
  • 20. © iteratec 20 Agenda  Erschlagen vom eigenen Erfolg  Fahrplan zu entspannten Live-Gängen  Definition von Lastanforderungen  Lasttests zur Überprüfung der Lastanforderungen  Auswahl der passenden Tools  Auswertung von Lasttests  Sizing der Systeme auf Basis von Lasttestergebnissen  Erfahrungen und Ergebnisse in der Praxis
  • 21. © iteratec 21 1. Testarten  Performance-Messung: Wie schnell ist das System ohne Last?  Lasttest: Wie verhält sich das System unter Last?  Stresstest: Wie kommt das System mit Überlastsituationen klar? 2. Umfang  Komponenten-Lasttest: Lasttest einzelner Komponenten  System-Lasttest: Lasttest des Gesamtsystems 3. Zielsetzungen  Entwicklungs-Lasttest: Untersuchung des Lastverhaltens, Identifikation von Engpässen  Abnahme-Lasttest: Überprüfung der Zielerreichung bzgl. Lastanforderungen Lasttests zur Überprüfung der Lastanforderungen Begriffsklärung
  • 22. © iteratec 22 1. Testarten  Performance-Messung: Wie schnell ist das System ohne Last?  Lasttest: Wie verhält sich das System unter Last?  Stresstest: Wie kommt das System mit Überlastsituationen klar? 2. Umfang  Komponenten-Lasttest: Lasttest einzelner Komponenten  System-Lasttest: Lasttest des Gesamtsystems 3. Zielsetzungen  Entwicklungs-Lasttest: Untersuchung des Lastverhaltens, Identifikation von Engpässen  Abnahme-Lasttest: Überprüfung der Zielerreichung bzgl. Lastanforderungen Lasttests zur Überprüfung der Lastanforderungen Begriffsklärung
  • 23. © iteratec 23 Lasttests zur Überprüfung der Lastanforderungen Typische Anforderung : Lineare Skalierbarkeit Anzahl User
  • 24. © iteratec 24  Messung mit linear steigender Last Lasttests zur Überprüfung der Lastanforderungen Beispiel: Durchsatzmessung in Abhängigkeit von der Last
  • 25. © iteratec 25  Messung mit linear steigender Last Lasttests zur Überprüfung der Lastanforderungen Beispiel: Durchsatzmessung in Abhängigkeit von der Last Lastkurve bei idealem Systemverhalten (lineare Skalierbarkeit)
  • 26. © iteratec 26  Messung mit linear steigender Last  grün: linearer Bereich, Antwortzeit ist konstant, auch bei steigender Last  gelb: nichtlinearer Bereich, Antwortzeiten beginnen zu steigen,  orange: Sättigung, Antwortzeiten steigen synchron zur Last  rot: Überlast, Antwortzeiten steigen stärker als die Last, der Durchsatz verringert sich mit weiterer Erhöhung der Last, Lasttests zur Überprüfung der Lastanforderungen Beispiel: Durchsatzmessung in Abhängigkeit von der Last Lastkurve bei idealem Systemverhalten (lineare Skalierbarkeit)
  • 27. © iteratec 27  Realistische Lasttests  möglichst viele der Requests, die in der Realität auftauchen  alle relevanten UseCases  statische Ressourcen, AJAX-Calls, Tracking-Requests, …  Mix der Requests (Häufigkeitsverteilung)  Sessionlänge  Abfolge der Requests  Think-Time  Datenvielfalt (Kategorien, Artikel, Suchbegriffe, Kunden, ...) Lasttests zur Überprüfung der Lastanforderungen Realistische Lasttests modellierter Lastanteil 90% 95% 98% 99% abzubildende UseCases 5-10 10-20 25-50 50-100
  • 28. © iteratec 28  Zufällige Lasttests  Deterministische Szenarien haben weniger Aussagekraft  testen nur ein konkretes Szenario und verbergen Fehler  finden Fehler, die in der Realität so nicht vorkommen werden  zufällige Testdaten, zufällige Session-Längen, zufällige Testschritt- Reihenfolgen, zufällige Wartezeiten (Think Time), zufällige Warenkorbgrößen  Praxis  Gewichtete Zufallsauswahl auf Basis relativer Häufigkeiten (CSV)  Auswahl Suchbegriff aus den Top-3000 Suchbegriffen der Kunden  Zufälliger Shuffle der Testschritt-Reihenfolge  Think-Time zwischen Testschritten Lasttests zur Überprüfung der Lastanforderungen Zufällige Lasttests
  • 29. © iteratec 29  Regelmäßige Lasttests  Lastziele werden nicht auf Anhieb erreicht  neue Fehler machen bereits erreichtes zunichte  Praxis  Automatisierte Komponenten-Lasttest in der Build-Pipeline  Automatisierte tgl. System-Lasttests + mehrfach individuell gestartete Lasttests am Tage  Automatisierte Abnahme-Lasttest in der Release-Pipeline Lasttests zur Überprüfung der Lastanforderungen Regelmäßige Lasttests
  • 30. © iteratec 30 Lasttests zur Überprüfung der Lastanforderungen Einordnung der Lasttests in die Build- und Release-Pipeline
  • 31. © iteratec 31 Perfor- mance Lasttest Robust- heit System-LPT Perfor- mance Lasttest Robust- heit Abnahme-LPT Lasttests zur Überprüfung der Lastanforderungen Einordnung der Lasttests in die Build- und Release-Pipeline Perfor- mance Lasttest Komponenten-LPT
  • 32. © iteratec 32 Agenda  Erschlagen vom eigenen Erfolg  Fahrplan zu entspannten Live-Gängen  Definition von Lastanforderungen  Lasttests zur Überprüfung der Lastanforderungen  Auswahl der passenden Tools  Auswertung von Lasttests  Sizing der Systeme auf Basis von Lasttestergebnissen  Erfahrungen und Ergebnisse in der Praxis
  • 33. © iteratec 33  Toolklassen  synthetische http-Request-Last (ab, JMeter, Silk Performer)  capture replay von realem Traffic (JMeter, Silk Performer, LoadRunner)  simulierte Browser (XLT)  ferngesteuerte Browser (Soke)  ferngesteuerte Rechner (viele WinRunner)  gesteuerte Menschengruppe  TradeOff  Hardware-Aufwand  Pflege-Aufwand / Realitätstreue Auswahl der passenden Tools Tool-Klassen
  • 34. © iteratec 34 Auswahl der passenden Tools HW-Bedarf Tool-Kategorie echte User echte Browser simulierte Browser HTTP-Traffic einfache HTTP- Lastsynthetisch capture / replay Realitätstreue max sehr hoch hoch mittel max gering Pflegeaufwand min gering gering hoch mittel mittel HW-Bedarf (für Ziellast) 2-5.000 PC 1-2.000 VM 50-100 VM 10-20 VM 3-5 VM open source Tools - •Soke •Soke •JMeter •Grinder •Gatling •Apache Bench •Siege kommerzielle Tools - •XLT •LoadRunner •SilkPerformer
  • 35. © iteratec 35 Auswahl der passenden Tools HW-Bedarf Tool-Kategorie echte User echte Browser simulierte Browser HTTP-Traffic einfache HTTP- Lastsynthetisch capture / replay Realitätstreue max sehr hoch hoch mittel max gering Pflegeaufwand min gering gering hoch mittel mittel HW-Bedarf (für Ziellast) 2-5.000 PC 1-2.000 VM 50-100 VM 10-20 VM 3-5 VM open source Tools - •Soke •Soke •JMeter •Grinder •Gatling •Apache Bench •Siege kommerzielle Tools - •XLT •LoadRunner •SilkPerformer
  • 36. © iteratec 36 Agenda  Erschlagen vom eigenen Erfolg  Fahrplan zu entspannten Live-Gängen  Definition von Lastanforderungen  Lasttests zur Überprüfung der Lastanforderungen  Auswahl der passenden Tools  Auswertung von Lasttests  Sizing der Systeme auf Basis von Lasttestergebnissen  Erfahrungen und Ergebnisse in der Praxis
  • 37. © iteratec 37 Auswertung von Lasttests Überblick über die Gesamtlandschaft Prelive-cluster 50 Lastgeneratoren (8 core, 8GB RAM) jenkins-lpt xltmaster-dev xltmaster-qa-166 xltmaster-qa-85 LoadBalancer PA-Proxy PA-Proxy Auth Order P13N Product … SAN LPT LoadBalancer PA-Proxy PA-Proxy Auth Order P13N Product … SAN Live LoadBalancer PA-Proxy PA-Proxy Auth Order P13N Product … SAN Graphite Splunk LoggingKPI
  • 38. © iteratec 38 Auswertung von Lasttests Auswertungen Prelive-cluster 50 Lastgeneratoren (8 core, 8GB RAM) jenkins-lpt xltmaster-dev xltmaster-qa-166 xltmaster-qa-85 LoadBalancer PA-Proxy PA-Proxy Auth Order P13N Product … SAN LPT LoadBalancer PA-Proxy PA-Proxy Auth Order P13N Product … SAN Live LoadBalancer PA-Proxy PA-Proxy Auth Order P13N Product … SAN Graphite Splunk LoggingKPI 1.XLT-Report 2.Splunk-Report3.Graphite-Graph 1.Antwortzeiten 2.(Profiling) Log 3.Ressourcen- Monitoring
  • 39. © iteratec 39  Durchsatz (Hits/s)  Durchsatz  User (Laufzeitprobleme ?)  Aktionen  Fehleranteil  Seitenladezeiten  Durchsatz / Aktion  Requests (Antwortzeiten, zeitlicher Verlauf)  Custom Timer (Auftreten von speziellen Fehlern, Detaillaufzeiten)  External Data (Externe Laufzeiten)  Error and Event (Fehlerbilder, Fehlerursachen)  Agents (Agent-Auslastung, Validität Messergebnisse) Auswertung von Lasttests 1 XLT-Report
  • 40. © iteratec 40  Verlängerung der Laufzeiten lässt Anzahl simulierter User überproportional steigen Auswertung von Lasttests 1 XLT-Report : Typische Fehlerbilder
  • 41. © iteratec 41  Stau auf der Datenautobahn Auswertung von Lasttests 1 XLT-Report : Typische Fehlerbilder Erwartete Kurve
  • 42. © iteratec 42  Einbruch nach Erreichen einer Lastgrenze = Überlast Auswertung von Lasttests 1 XLT-Report : Typische Fehlerbilder
  • 43. © iteratec 43  zunehmende Anzahl Timeouts lässt durchschnittliche Laufzeit kontinuierlich steigen Auswertung von Lasttests 1 XLT-Report : Typische Fehlerbilder
  • 44. © iteratec 44 Live Demo Auswertung von Lasttests 1. XLT-Report
  • 45. © iteratec 45  Ziel: Fehlerbild in der Anwendung ermitteln  Whitebox-Sicht  Basis: Performance-Logs der Anwendung  Log-Dateien aller beteiligten Maschinen werden durch Splunk eingesammelt und zentral indexiert und bereitgestellt  Konsolidierung über Maschinengrenzen hinweg  Konsolidierung über LogFile-Typen hinweg  Dynamische AdHoc Queries möglich  Explorative Untersuchung der Performance-Kennzahlen  Detaillierung bis hin zum einzelnen Request  Herausforderung:  Zielsystem besteht aus einem Dutzend separaten Teilsystemen  Welches Teilsystem ist für Performanceprobleme verantwortlich ? Auswertung von Lasttests 2 Splunk-Report
  • 46. © iteratec 46 RESTful Architektur1 Shared Nothing als Architekturprinzip 2 Vertikaler Systemschnitt 3 Zentrale Verantwort- lichkeit für Daten 4 Buy when non coreA Gemeinsame Basistechnologien B Macro-Architektur Micro-Architektur Shopoffice Shoppages Search&Navigation Product Personalisation Order User Tracking Auth AfterSales ELCH Frontend-Integration Daten-Integration Vertikale Systemarchitektur des Zielsystems Funktionale Gliederung
  • 47. © iteratec 47 Shopoffice Shoppages Search&Navigation(SAN) Product Personalisation (P13N) Order User Tracking Auth AfterSales ELCH Frontend-Integration Daten-Integration Vertikale Systemarchitektur des Zielsystems Seitenkomposition  Der Seitenrahmen und der Hauptinhalt kommt aus dem product- System  Der Miniwarenkorb liefert das order-System  Die Navigation wird vom san-System bereitgestellt  Die Produktempfehlungen stammen aus dem p13n-System
  • 48. © iteratec 48  Dashboard  Client  Backend Request Laufzeiten  Aufteilung nach PageTag  Welches System ist für Laufzeitprobleme verantwortlich ? Auswertung von Lasttests 2 Splunk-Report
  • 49. © iteratec 49 Live-Demo Auswertung von Lasttests 2 Splunk-Report
  • 50. © iteratec 50  Rubriken für Ressourcenauslastung  Physikalische Systemressourcen  CPU  Platten-IO  RAM  Netzwerk-IO  Logische SW-Ressourcen  Plattform (Tomcat Threadpool, Java GC)  Anwendung (Pools, Queues, Synchronisation nebenläufiger Threads)  Verlinkung Jenkins-Job  Graphoo Dashboards  Details zur Ressourcenauslastung aller Maschinen  Übersichts-Dashboard zu Performance- und Lasttests  Graphoo = eigene Rails-Anwendung  dynamische Generierung der Dashboards mit Graphite-Grafiken  Basis : aktuelles Inventory der Umgebung + Dashboard-Config Auswertung von Lasttests 3. Graphite-Graphen
  • 51. © iteratec 51  Graphoo Dashboard mit Graphite-Grafiken Auswertung von Lasttests 3. Graphite-Graphen
  • 52. © iteratec 52 Live-Demo Auswertung von Lasttests 3. Graphite-Graphen
  • 53. © iteratec 53 Agenda  Erschlagen vom eigenen Erfolg  Fahrplan zu entspannten Live-Gängen  Definition von Lastanforderungen  Lasttests zur Überprüfung der Lastanforderungen  Auswahl der passenden Tools  Auswertung von Lasttests  Sizing der Systeme auf Basis von Lasttestergebnissen  Erfahrungen und Ergebnisse in der Praxis
  • 54. © iteratec 54 1. Messung der Spitzenlast im Lasttest 2. Messung der Ressourcenauslastung während des Lasttests 3. Messung der zugeordneten Ressourcen in der Lastumgebung 4. Vorgabe der Ziellast 5. Vorgabe der Ressourcenauslastung bei Ziellast  Lastreserve  Ausfallreserve 6. Vorgaben zum Server-/VM-Zuschnitt  minimale Anzahl Server/VM‘s pro Komponente  Ressourcen pro Server/VM 7. Extrapolation der benötigten Ressourcen in der Zielumgebung Sizing der Systeme auf Basis von Lasttestergebnissen Vorgehen )( )( )( )( Re Re **)()( ReRe live Test Test live radslastungsgssourcenau radslastungsgssourcenau Last Ziellast ngTestumgebulive ssourcendarfssourcenbe 
  • 55. © iteratec 55  Vorgabe Ressourcenauslastung bei Ziellast  Lineare Skalierbarkeit auf einer Maschine nur bis max. 50-70% Ressourcenauslastung erreichbar  Ausfallsicherheitsreserve 50%  Ziel-Wert: 50% * 60% = 30%  Vorgaben zum Server-/VM-Zuschnitt  Ausfallsicherheit:  AppServer: mindestens zwei Server pro Aufgabe  MongoDB Replica-Set: mindestens 3 DBs im Replica-Verbund  Ressourcen pro Server  mindestens 2 core pro Server/VM (System + Applikation)  nie swapping zulassen  ausreichend memory  minimale disk size für sicheren Betrieb (logging, backup/restore) Sizing der Systeme auf Basis von Lasttestergebnissen Grundannahmen
  • 56. © iteratec 56 Agenda  Erschlagen vom eigenen Erfolg  Fahrplan zu entspannten Live-Gängen  Erfahrungen und Ergebnisse in der Praxis
  • 57. © iteratec 57  Kontinuierliche Lasttests seit 12 Monaten  6 Ziel-Umgebungen, davon 3 für Lasttests genutzt  Je Umgebung zwischen 50 und 150 VM  50 VM‘s als Lastgeneratoren  5-10 Lasttestläufe pro Tag  5-10 GByte Ergebnisdaten pro Lasttestlauf  ca. 100 Metriken pro VM pro Minute  ca. 100 GByte tägliches Log-Volumen aus Lasttests  3 große Meilensteine erfolgreich bewältigt  Mitarbeitershop  Closed Alpha  Live Beta Erfahrungen und Ergebnisse in der Praxis Zahlen
  • 58. © iteratec 58  Ohne smarte Ziele geht es nicht.  S = Spezifisch  M = Messbar  A = Akzeptiert  R = Realistisch  T = Terminiert Erfahrungen und Ergebnisse in der Praxis Lessons learned
  • 59. © iteratec 59  Ohne smarte Ziele geht es nicht.  S = Spezifisch  M = Messbar  A = Akzeptiert  R = Realistisch  T = Terminiert  Zielerreichung laufend kommunizieren und visualisieren  Dashboard Erfahrungen und Ergebnisse in der Praxis Lessons learned
  • 60. © iteratec 60  Arbeitsstand für alle sichtbar visualisieren: Dashboard Erfahrungen und Ergebnisse in der Praxis Dashboard
  • 61. © iteratec 61  Ohne smarte Ziele geht es nicht.  S = Spezifisch  M = Messbar  A = Akzeptiert  R = Realistisch  T = Terminiert  Zielerreichung laufend kommunizieren und visualisieren  Dashboard  Die Probleme treten meist nicht dort auf, wo man sie vermutet.  Lasttest so dicht wie möglich an der Wirklichkeit gestalten  BlackBox Test Erfahrungen und Ergebnisse in der Praxis Lessons learned
  • 62. © iteratec 62 erreichterDurchsatz Projektlaufzeit Erfahrungen und Ergebnisse in der Praxis Beispiele für aufgedeckte Skalierbarkeitsprobleme Problem: Default-Konfiguration des nginx beschränkt CPU-Nutzung auf einen Core Lösung: Anpassung nginx-Konfiguration
  • 63. © iteratec 63 erreichterDurchsatz Projektlaufzeit Erfahrungen und Ergebnisse in der Praxis Beispiele für aufgedeckte Skalierbarkeitsprobleme Problem: Auslieferung statischer Ressourcen setzt App-Server unter Last Lösung: Einführung Asset-Server für statischen Content
  • 64. © iteratec 64 erreichterDurchsatz Projektlaufzeit Erfahrungen und Ergebnisse in der Praxis Beispiele für aufgedeckte Skalierbarkeitsprobleme Problem: zu wenig RAM führt unter Last zum Swapping der Such-Server Lösung: mehr RAM
  • 65. © iteratec 67  Ziele müssen allgemein akzeptiert werden  SMART  Zielerreichung laufend kommunizieren  Dashboard  Probleme meist nicht dort, wo man sie vermutet  Wirklichkeitsnähe Entspannte Live-Gänge in Sachen Performance- und Lastverhalten sind keine Utopie Erfahrungen und Ergebnisse in der Praxis Konsequenzen für die Gestaltung der Lasttests
  • 66. © iteratec 68 Eure Fragen ? Kontakt: Uwe.Bessle@iteratec.de Iteratec GmbH