Your SlideShare is downloading. ×
0
Performance und Skalierbarkeit zum
Anfassen und Nachmessen
Effektiver Einsatz von Performance-Messungen und Lasttests
zur ...
Anforderungen an IT-Systeme
Klassifizierung nach ISO/IEC 9126 / 25000 bzw. DIN 66272


Funktionalität




Zuverlässigke...
 Erschlagen

vom eigenen Erfolg

 Herausforderungen
 Fahrplan

im Lhotse-Kontext

zu entspannten Live-Gängen

 Erfahru...
Vom eigenen Erfolg erschlagen
DaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen

6


Quelle: http://de.dawanda.c...
Vom eigenen Erfolg erschlagen
Telekom Mobilfunkseite durch iPhone5 Andrang

14.09.2012

7


Quelle: http://www.heise.de/m...
Vom eigenen Erfolg erschlagen
Rockstar Spieleserver : Probleme beim Start von Online-GTA-5

01.10.2013

8


© iteratec
Qu...
Vom eigenen Erfolg erschlagen
GovData: www.daten-deutschland.de vom Start weg überlastet

20.02.2013

9


Quelle: http://...
Vom eigenen Erfolg erschlagen
healthcare.gov : Auch drei Wochen nach dem Start noch ein Desaster

21.10.2013

10


Quelle...
Agenda

 Erschlagen

vom eigenen Erfolg

 Herausforderungen

im Lhotse-Kontext



Vertikale Systemarchitektur



Agile...
Lhotse
Eckpunkte
 Lhotse


Projekt zum Neubau von www.otto.de



Start 2011



Go-Live 24.10.2013



>100 Mitarbeiter...
Herausforderungen im Lhotse-Kontext
Vertikale Systemarchitektur : Viele separate Systeme
Macro-Architektur
1
2

Tracking

...
Herausforderungen im Lhotse-Kontext
Agiles Vorgehensmodell : Architektur entsteht „by the way“ ?!

14
© iteratec
Herausforderungen im Lhotse-Kontext
Wozu brauche ich Lasttests, ich habe doch die Cloud ?
Internet

Firewall

 Grundidee:...
Herausforderungen im Lhotse-Kontext
Zielsetzung: Horizontale Skalierung
Internet

Firewall
LoadBalancer
WebServer

WebServ...
Herausforderungen im Lhotse-Kontext
Architektur-Komponenten ohne horizontale Skalierbarkeit
Theory meets Reality

Internet...
Herausforderungen im Lhotse-Kontext
Steigende Anforderungen im Projektverlauf
 Mehr Artikel
 Mehr

Kunden, mehr Visits

...
Fahrplan zu entspannten Live-Gängen






Definition von Performance-/Lastanforderungen
Konzeption geeigneter Perform...
Performance- und Lastanforderungen

AS
Browser

PAProxy
Browser

DSLAM

PC

Internet

FW

LB

AS

AS
PAProxy
AS

Browser

...
Performance- und Lastanforderungen
Performance
AS
Browser

PAProxy
Browser

DSLAM

PC

Browser

Internet

FW

LB

AS

AS
P...
Performance- und Lastanforderungen
Last
AS
Browser

PAProxy
Browser

DSLAM

Internet

PC

Browser

Veränderung der
Antwort...
Performance-Anforderungen
„Wie schnell wollen / müssen wir sein?“

23
© iteratec
Performance-Anforderungen
Analyse bestehender Methoden und Kriterien
Kundenzufriedenheit

Traffic

Google-Analytics
gut
sc...
Performance-Anforderungen
Usability-Test: Wie zufrieden sind Benutzer mit der Ladezeit?
100%

90%

3. Iteration

Ladezeit ...
Performance-Anforderungen
Usability-Test: Wie zufrieden sind Benutzer mit der Ladezeit?
100%

Seitentyp 1 1. It
Seitentyp ...
Performance-Anforderungen
Customer Satisfaction Index (CSI)

Gewichtungsfaktor
Seitenart

Gewichtungsfaktor
Tageszeit

Gew...
Last-Anforderungen

„Wieviel müssen wir aushalten können?“

28
© iteratec
Definition von Lastanforderungen
Woher kommen konkrete Anforderungen ?
Fachliche Planzahlen
• Business Case
• Benchmarking...
Definition von Lastanforderungen
Quellen für Anforderungen
 Seitenverteilung

aus dem Web-Tracking

30
© iteratec
Definition von Lastanforderungen
Betrachtungs-Zeitraum : Typische Tageskurve
Page views / h
1.000.000
900.000
800.000
700....
Definition von Lastanforderungen
Betrachtungs-Zeitraum : Monatsverlauf

maßgebliches Ziel
für Lasttest

relevante Kennzahl...
Agenda

 Erschlagen

vom eigenen Erfolg

 Herausforderungen
 Fahrplan

im Lhotse-Kontext

zu entspannten Live-Gängen

...
Konzeption Performance-Messungen
Anforderungen an Messmethode
„Realistisch“?
Soll: Wie performt die Applikation beim Kunde...
Konzeption Performance-Messungen
Synthetische Messungen  Real User Monitoring

Synthetische Messung

Real User Monitoring...
Konzeption Performance-Messungen
Synthetische Performance-Messungen: WebPagetest
Wichtige Eigenschaften:
 Reale PC-Umgebu...
Konzeption Performance-Messungen
Real User Monitoring : Browser Navigation Timing API

39
© iteratec
Lasttests zur Überprüfung der Lastanforderungen
Typische Anforderung : Lineare Skalierbarkeit

Anzahl User
40
© iteratec
Lasttests zur Überprüfung der Lastanforderungen
Beispiel: Durchsatzmessung in Abhängigkeit von der Last
 Messung


mit l...
Lasttests zur Überprüfung der Lastanforderungen
Anforderungen an Lasttests
 Realistische


Lasttests

möglichst viele de...
Agenda

 Erschlagen

vom eigenen Erfolg

 Herausforderungen
 Fahrplan

im Lhotse-Kontext

zu entspannten Live-Gängen

...
Aufbau einer passenden Umgebung
LPT-Testumgebung
WebPageTest Performance-Messungen
XLT Lasttests

Develop-ci
(CI)

Develop...
Aufbau einer passenden Umgebung
Sizing der LPT-Testumgebung

Der beste Maßstab für ein Modell ist 1:1
 LPT

ist Live-glei...
Performance-Messumgebung
WebPagetest
„Portal“
extern

intern

WPTMonitor

WPTMonitor

WPTServer1

WPTServer2

WPT-Server

...
Performance-Messumgebung
Real User Monitoring

Browser

DSLAM

Internet

PC

JavaScript
Mess-Script

AssetServer
FW

LB

G...
Lasttestumgebung
Tool-Klassen
 Toolklassen


Synth. http-Request-Last (Apache Bench, JMeter, Silk Performer)



capture...
Lasttestumgebung
Lasttest auf der Basis von HTTP-Requests
AS
Browser

Browser

Lasttest-Tool
(muss Logik im
DSLAM

PC

Int...
Lasttestumgebung
Simulierte Browser in Xceptance Load Test (XLT)

Xceptance Load Test
AS
HTMLunit

PAProxy
HTMLunit

PC

I...
Lasttestumgebung
Überblick über die Gesamtlandschaft

jenkins

xltmaster-01

xltmaster-02

100-500 Lastgeneratoren (8 core...
Lastumgebung
Kosten
 Lasttests

laufen selten 24*7 Typisches Thema für die Cloud

 1. Ansatz: Amazon

EC2



Kann alle...
Agenda

 Erschlagen

vom eigenen Erfolg

 Herausforderungen
 Fahrplan

im Lhotse-Kontext

zu entspannten Live-Gängen

...
Auswertung von Lasttests
Auswertungen

jenkins

1.XLT-Report
xltmaster-01

xltmaster-02

500 Lastgeneratoren (8 core, 16GB...
Auswertung von Lasttests
1 XLT-Report
 Durchsatz

(Hits/s)

 Durchsatz

 User (Laufzeitprobleme ?)

 Aktionen


Fehle...
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
 Verlängerung

der Laufzeiten lässt Anzahl simulierter User...
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
 Stau

auf der Datenautobahn

Erwartete Kurve

62
© iterate...
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
 Einbruch

nach Erreichen einer Lastgrenze = Überlast

63
©...
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
 zunehmende Anzahl

Timeouts (graue Spikes) lässt
durchschn...
Die vertikale Systemarchitektur
Herausforderung: Verursacher identifizieren
 Der Seitenrahmen und der Hauptinhalt kommt
a...
Auswertung von Lasttests
2 Splunk-Report
 Dashboard
 Client

 Backend Request Laufzeiten

 Aufteilung
 Welches

nach ...
Lasttestumgebung
Ermittlung der Verursacher von Laufzeitproblemen in Splunk
AS
Browser

PAProxy
Browser

Internet

DSLAM

...
Auswertung von Lasttests
3. Graphite-Graphen
 Rubriken

für Ressourcenauslastung



CPU



Platten-IO



RAM



Netzw...
Auswertung von Lasttests
3. Graphite-Graphen : Low Level Sicht auf Maschinen-Ressourcen
 Graphite

Dashboard

72
© iterat...
Auswertung von Lasttests
3. Graphite-Graphen : High Level Sichten



Sicht auf Systeme (Vertikalen)



Logische Sicht au...
Agenda

 Erschlagen

vom eigenen Erfolg

 Herausforderungen
 Fahrplan

im Lhotse-Kontext

zu entspannten Live-Gängen

...
Sizing der Systeme auf Basis von Lasttestergebnissen
Vorgehen
1. Messung der Spitzenlast im Lasttest
2. Messung der Ressou...
Agenda

 Erfahrungen

und Ergebnisse in der Praxis

78
© iteratec
Erfahrungen und Ergebnisse in der Praxis



Zahlen
 Kontinuierliche
6

Lasttests seit 18 Monaten

Ziel-Umgebungen, davo...
Erfahrungen und Ergebnisse in der Praxis



Zahlen
 Live-Gang

und alle vorherigen Meilensteine erfolgreich

bewältigt
S...
Erfahrungen und Ergebnisse in der Praxis
Lessons learned


Ohne smarte Ziele geht es nicht.



M = Messbar



A = Akze...
Erfahrungen und Ergebnisse in der Praxis
Dashboard I (agiler Start)
 Arbeitsstand

für alle sichtbar visualisieren: Dashb...
Erfahrungen und Ergebnisse in der Praxis
Dashboard II

84
© iteratec
Erfahrungen und Ergebnisse in der Praxis
Lessons learned


Ohne smarte Ziele geht es nicht.



M = Messbar



A = Akze...
Probleme treten nicht dort auf, wo man sie erwartet
Beispiel SSL-Zertifikate
 Langsame

Zertifikate

 Insgesamt

548 + 5...
Probleme treten nicht dort auf, wo man sie erwartet
Beispiel SSL-Zertifikate
 Schnelle

Zertifikate

 Nur

noch 225 + 51...
Probleme treten nicht dort auf, wo man sie erwartet
Beispiel SSL-Zertifikate
 Auswirkungen

auf das Laden der Homepage : ...
Erfahrungen und Ergebnisse in der Praxis
Aufgedeckte Performance-/Skalierbarkeitsprobleme (lila)
AS
Browser

PAProxy
Brows...
Erfahrungen und Ergebnisse in der Praxis

Entspannte Live-Gänge in Sachen Performance- und
Lastverhalten sind keine Utopie...
Ihre Fragen ?

Kontakt: Uwe.Bessle@iteratec.de
Iteratec GmbH

106
© iteratec
Upcoming SlideShare
Loading in...5
×

DevCon-2013-PerformanceSkalierbarkeit_UweBessle

679

Published on

DevCon 2013 - Performance und Skalierbarkeit zum Anfassen und Nachmessen

Published in: Technology
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total Views
679
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
25
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "DevCon-2013-PerformanceSkalierbarkeit_UweBessle"

  1. 1. Performance und Skalierbarkeit zum Anfassen und Nachmessen Effektiver Einsatz von Performance-Messungen und Lasttests zur Optimierung der Performance und Skalierbarkeit einer großen eCommerce Plattform 8. November 2013 Uwe.Bessle@iteratec.de
  2. 2. Anforderungen an IT-Systeme Klassifizierung nach ISO/IEC 9126 / 25000 bzw. DIN 66272  Funktionalität   Zuverlässigkeit   Zeitverhalten, Verbrauchsverhalten Wartbarkeit/Änderbarkeit   Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität Effizienz   Reife, Fehlertoleranz, Wiederherstellbarkeit Benutzbarkeit   Angemessenheit, Richtigkeit, Interoperabilität, Sicherheit, Ordnungsmäßigkeit Analysierbarkeit, Modifizierbarkeit, Stabilität, Testbarkeit Übertragbarkeit  Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit 3 © iteratec
  3. 3.  Erschlagen vom eigenen Erfolg  Herausforderungen  Fahrplan im Lhotse-Kontext zu entspannten Live-Gängen  Erfahrungen und Ergebnisse in der Praxis 5 © iteratec
  4. 4. Vom eigenen Erfolg erschlagen DaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen 6  Quelle: http://de.dawanda.com/topic/2169/10130642 © iteratec
  5. 5. Vom eigenen Erfolg erschlagen Telekom Mobilfunkseite durch iPhone5 Andrang 14.09.2012 7  Quelle: http://www.heise.de/mac-and-i/meldung/iPhone-Vorbestellung-ueberlastet-Telekom-1708303.html © iteratec
  6. 6. Vom eigenen Erfolg erschlagen Rockstar Spieleserver : Probleme beim Start von Online-GTA-5 01.10.2013 8  © iteratec Quelle: http://www.onlinewelten.com/games/gta-online/news/server-ueberlastet-probleme-start-online-gta-5-update-rockstar-aeussert-123409/
  7. 7. Vom eigenen Erfolg erschlagen GovData: www.daten-deutschland.de vom Start weg überlastet 20.02.2013 9  Quelle: http://www.computerwoche.de/a/datenportal-der-bundesregierung-startet-holprig,2533210 © iteratec
  8. 8. Vom eigenen Erfolg erschlagen healthcare.gov : Auch drei Wochen nach dem Start noch ein Desaster 21.10.2013 10  Quelle: http://www.tagesschau.de/ausland/usa612.html © iteratec
  9. 9. Agenda  Erschlagen vom eigenen Erfolg  Herausforderungen im Lhotse-Kontext  Vertikale Systemarchitektur  Agiles Vorgehensmodell im Entwicklungsprozess  Auch die Cloud ist kein Allheilmittel  Steigende Anforderungen im Projektverlauf  Fahrplan zu entspannten Live-Gängen  Erfahrungen und Ergebnisse in der Praxis 11 © iteratec
  10. 10. Lhotse Eckpunkte  Lhotse  Projekt zum Neubau von www.otto.de  Start 2011  Go-Live 24.10.2013  >100 Mitarbeiter  8 Teams  11 Systeme + zahlreiche unterstützende Anwendungen  Ziele  Mehr (Sortimentsvolumen, Kunden)  Schneller (Echtzeitdaten im Frontend)  Individueller (Personalisierung)  Einfacher (Plattformvereinfachung)  Besser (Test-Driven, Data-Driven) 12 © iteratec
  11. 11. Herausforderungen im Lhotse-Kontext Vertikale Systemarchitektur : Viele separate Systeme Macro-Architektur 1 2 Tracking ELCH Auth After Sales User Order Personalisation (P13N) Product Search & Navigation (SAN) Shoppages Shopoffice Vertikaler Systemschnitt 4 Daten-Integration Shared Nothing als Architekturprinzip 3 Frontend-Integration RESTful Architektur Zentrale Verantwortlichkeit für Daten & Datenversorgungsprozesse A Buy when non core B Gemeinsame Basistechnologien Micro-Architektur 13 © iteratec
  12. 12. Herausforderungen im Lhotse-Kontext Agiles Vorgehensmodell : Architektur entsteht „by the way“ ?! 14 © iteratec
  13. 13. Herausforderungen im Lhotse-Kontext Wozu brauche ich Lasttests, ich habe doch die Cloud ? Internet Firewall  Grundidee:  WebServer  + horizontale Skalierbarkeit der Anwendungskomponenten + dynamisches Buchen zusätzlicher Ressourcen in der Cloud  WebServer Einsatz von Standardkomponenten zur Lastverteilung (Load-Balancer)  LoadBalancer = Lastprobleme einfach gelöst LoadBalancer AppServer Auth (LDAP) AppServer AppServer Datenbank 15 © iteratec
  14. 14. Herausforderungen im Lhotse-Kontext Zielsetzung: Horizontale Skalierung Internet Firewall LoadBalancer WebServer WebServer WebServer WebServer LoadBalancer AppServer Auth (LDAP) AppServer AppServer AppServer AppServer Datenbank 16 © iteratec
  15. 15. Herausforderungen im Lhotse-Kontext Architektur-Komponenten ohne horizontale Skalierbarkeit Theory meets Reality Internet  typische Bottlenecks: alles was zentral ist Firewall   WebServer WebServer  WebServer LoadBalancer AppServer Auth (LDAP) AppServer AppServer Datenbank AppServer zentraler Load-Balancer, zentrale Datenbank,  WebServer Firewall,  LoadBalancer RZ-Anbindung, zentraler Authentication Server (LDAP) AppServer  typisches Problem: Implementierungsfehler hebeln Skalierbarkeit aus 17 © iteratec
  16. 16. Herausforderungen im Lhotse-Kontext Steigende Anforderungen im Projektverlauf  Mehr Artikel  Mehr Kunden, mehr Visits  Mehr Features auf den Seiten  Mehr Personalisierung  Schnellere Seitenladezeiten  2012: 80% CSI  1.7.2013: 85% CSI  31.12.2013: 90% CSI  Mehr Seitenaufrufe  2012: max= 423 PI/s  1.9.2013: Ziel = 500 PI/s  1.10.2013: Ziel = 750 PI/s 18 © iteratec
  17. 17. Fahrplan zu entspannten Live-Gängen      Definition von Performance-/Lastanforderungen Konzeption geeigneter Performance-Messungen und Lasttests Aufbau einer passenden Umgebung Regelmäßige Durchführung und Auswertung Sizing der Systeme auf Basis von Lasttestergebnissen 19 © iteratec
  18. 18. Performance- und Lastanforderungen AS Browser PAProxy Browser DSLAM PC Internet FW LB AS AS PAProxy AS Browser AS DSLAM Browser AS Es geht immer irgendwie um Antwortzeiten, aber ... 20 © iteratec
  19. 19. Performance- und Lastanforderungen Performance AS Browser PAProxy Browser DSLAM PC Browser Internet FW LB AS AS PAProxy AS AS Seitenladezeit für DSLAM Browser Benutzer im Client AS 21 © iteratec
  20. 20. Performance- und Lastanforderungen Last AS Browser PAProxy Browser DSLAM Internet PC Browser Veränderung der Antwortzeiten unter Last FW LB AS AS PAProxy AS AS DSLAM Browser AS 22 © iteratec
  21. 21. Performance-Anforderungen „Wie schnell wollen / müssen wir sein?“ 23 © iteratec
  22. 22. Performance-Anforderungen Analyse bestehender Methoden und Kriterien Kundenzufriedenheit Traffic Google-Analytics gut schlecht Google Suchtrefferseite* 120 % 100 % 80% 60% 40% 20% -20% Ladezeit (s) Ladezeit (s) 0 1 2 3 4 5 n 0 0,5 1 1,5 n *http://glinden.blogspot.de/2006/11/marissa-mayer-at-web-20.html Zufriedenheit satisfied APDEX* tolerating frustrated Strangeloop-Studie* * http://www.strangeloopnetworks.com/web-performance-infographics/ tml Ladezeit 0 4T T Default threshold: T = 4 sec, Ableitung eines Index 0-1 * http://apdex.org/index.php/about/ 24 © iteratec
  23. 23. Performance-Anforderungen Usability-Test: Wie zufrieden sind Benutzer mit der Ladezeit? 100% 90% 3. Iteration Ladezeit bei der 100% der User zufrieden sind 2. Iteration 1. Iteration 80% 70% 60% Ladezeit bei der 75% der User zufrieden sind 50% 40% Erwartungen wachsen mit der Anzahl der Besuche 30% 20% 10% 0,3 0,7 1,1 1,5 1,9 2,3 2,7 3,1 3,5 3,9 4,3 4,7 5,1 5,5 5,9 6,3 6,7 7,1 7,5 7,9 8,3 8,7 9,1 9,5 9,9 10,3 10,7 11,1 11,5 11,9 12,3 12,7 13,1 13,5 13,9 14,3 14,7 15,1 15,5 15,9 0% 25 © iteratec
  24. 24. Performance-Anforderungen Usability-Test: Wie zufrieden sind Benutzer mit der Ladezeit? 100% Seitentyp 1 1. It Seitentyp 2 1. It. 90% Seitentyp 3 3. It 80% Seitentyp 3 1. It Seitentyp 4 1. It 70% Seitentyp 5 1. It 60% Zufriedenheit 50% mit Ladezeit 40% 30% 20% 0% 0,3 0,9 1,5 2,1 2,7 3,3 3,9 4,5 5,1 5,7 6,3 6,9 7,5 8,1 8,7 9,3 9,9 10,5 11,1 11,7 12,3 12,9 13,5 14,1 14,7 15,3 15,9 16,5 17,1 17,7 18,3 18,9 19,5 20,1 20,7 21,3 21,9 22,5 23,1 10% Ladezeit (s) 26 © iteratec
  25. 25. Performance-Anforderungen Customer Satisfaction Index (CSI) Gewichtungsfaktor Seitenart Gewichtungsfaktor Tageszeit Gewichtungsfaktor Browserverteilung Ladezeit -> Zufriedenheit Gewichtungsfaktor XYZ ? 90% Einzelzufriedenheiten Ladezeit: Kontinuierliche Messung der Ladezeit von relevanten Seiten. Seitenart: Gewichtung der PIs pro Seitenart (Häufig aufgerufene Seiten wichtiger) Tageszeit: Gewichtung nach Umsatz / Traffic (Abendstunden wichtiger) Browserverteilung: Gewichtung nach Browser-Marktanteilen (Firefox wichtiger als IE) 27 © iteratec
  26. 26. Last-Anforderungen „Wieviel müssen wir aushalten können?“ 28 © iteratec
  27. 27. Definition von Lastanforderungen Woher kommen konkrete Anforderungen ? Fachliche Planzahlen • Business Case • Benchmarking (Wettbewerber) Interviews • • • • Nutzung des Altsystem Business Development Fachabteilung Betrieb ... • Web-Tracking (fachliche Kennzahlen) ! • Monitoring (technische Kennzahlen) Lastanforderungen 29 © iteratec
  28. 28. Definition von Lastanforderungen Quellen für Anforderungen  Seitenverteilung aus dem Web-Tracking 30 © iteratec
  29. 29. Definition von Lastanforderungen Betrachtungs-Zeitraum : Typische Tageskurve Page views / h 1.000.000 900.000 800.000 700.000 600.000 500.000 400.000 300.000 200.000 100.000 0 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 31 © iteratec
  30. 30. Definition von Lastanforderungen Betrachtungs-Zeitraum : Monatsverlauf maßgebliches Ziel für Lasttest relevante Kennzahl für Businessplan 32 © iteratec
  31. 31. Agenda  Erschlagen vom eigenen Erfolg  Herausforderungen  Fahrplan im Lhotse-Kontext zu entspannten Live-Gängen  Definition von Performance-/Lastanforderungen  Konzeption geeigneter Performance-Messungen und Lasttests  Aufbau einer passenden Umgebung  Regelmäßige Durchführung und Auswertung  Sizing der Systeme auf Basis von Lasttestergebnissen  Erfahrungen und Ergebnisse in der Praxis 35 © iteratec
  32. 32. Konzeption Performance-Messungen Anforderungen an Messmethode „Realistisch“? Soll: Wie performt die Applikation beim Kunden? Client-Messungen Backbone-Messungen Messpunkt Einflussfaktoren Server • Standort • Caching • CDN • Auslastung • BackendLatenzen • …. Backbone • Anbindung Last Mile • Bandbreite • Verbindungsart (DSL, UMTS, …) Client • Hard- und Software Ausstattung • Allgemeine Performance Browser • Hersteller • Version Frontend Logik • Codequalität 36 © iteratec
  33. 33. Konzeption Performance-Messungen Synthetische Messungen  Real User Monitoring Synthetische Messung Real User Monitoring Pro Pro • Reproduzierbar • Steuerbar • Klare Signale Contra • Bilden nicht die Realität ab • Kein Blick auf den Kunden • Keine Verfügbarkeitsaussagen • Zeigen was beim Kunden ankommt • Mengen-/Verfügbarkeitsaussagen Contra • Nicht reproduzierbar • Fehlsignale durch schlechte Kundenanbindungen Nicht entweder/oder sondern sowohl als auch 37 © iteratec
  34. 34. Konzeption Performance-Messungen Synthetische Performance-Messungen: WebPagetest Wichtige Eigenschaften:  Reale PC-Umgebung (Windows XP / Windows 7)  Echte Browser (IE, FF, Chrome)  Simulation der Internet-Anbindung (z.B. ISDN, DSL, UMTS)  Berücksichtigung des Browser-Cache (mit / ohne Cache)  Berücksichtigung von Cookies, JS, etc. Relevante KPIs:  Wann beginnt der Browser mit der Anzeige?: Start Render  Wann ist die Seite „interaktionsbereit“ geladen?: Document Complete  Wann sind alle Inhalte (inkl. Nachgeladene) geladen?: Fully Loaded  Wann sind alle visuellen Inhalte geladen?: Visually Complete  Keine Verfügbarkeitsmessung Messzeitpunkt: Welches ist der für Nutzer relevante Zeitpunkt eines “Seite fertig geladen” Gefühls? 38 © iteratec
  35. 35. Konzeption Performance-Messungen Real User Monitoring : Browser Navigation Timing API 39 © iteratec
  36. 36. Lasttests zur Überprüfung der Lastanforderungen Typische Anforderung : Lineare Skalierbarkeit Anzahl User 40 © iteratec
  37. 37. Lasttests zur Überprüfung der Lastanforderungen Beispiel: Durchsatzmessung in Abhängigkeit von der Last  Messung  mit linear steigender Last grün: linearer Bereich, Antwortzeit ist konstant, auch bei steigender Last Lastkurve bei idealem Systemverhalten (lineare Skalierbarkeit)  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, 43 © iteratec
  38. 38. Lasttests zur Überprüfung der Lastanforderungen Anforderungen an Lasttests  Realistische  Lasttests möglichst viele der Requests, die in der Realität auftauchen modellierter Lastanteil 90% 95% 98% 99% abzubildende UseCases 5-10 10-20 25-50 50-100  Mix der Requests (Häufigkeitsverteilung), Abfolge der Requests  Sessionlänge, Think-Time  Datenvielfalt (Kategorien, Artikel, Suchbegriffe, Kunden, ...)  Zufällige Lasttests  Deterministische Szenarien haben weniger Aussagekraft  zufällige Testdaten, zufällige Session-Längen, zufällige ...  Regelmäßige Lasttests  Lastziele werden nicht auf Anhieb erreicht  neue Fehler machen bereits erreichtes zunichte 44 © iteratec
  39. 39. Agenda  Erschlagen vom eigenen Erfolg  Herausforderungen  Fahrplan im Lhotse-Kontext zu entspannten Live-Gängen  Definition von Performance-/Lastanforderungen  Konzeption geeigneter Performance-Messungen und Lasttests  Aufbau einer passenden Umgebung  Regelmäßige Durchführung und Auswertung  Sizing der Systeme auf Basis von Lasttestergebnissen  Erfahrungen und Ergebnisse in der Praxis 45 © iteratec
  40. 40. Aufbau einer passenden Umgebung LPT-Testumgebung WebPageTest Performance-Messungen XLT Lasttests Develop-ci (CI) Develop (QA) LPT (Last+Perf. Test) Prelive (Abnahme) Live Real User Monitoring Continuous Delivery (Release Pipeline) 46 © iteratec
  41. 41. Aufbau einer passenden Umgebung Sizing der LPT-Testumgebung Der beste Maßstab für ein Modell ist 1:1  LPT ist Live-gleich aufgebaut  Wer kann das bezahlen?  You have to build things three times  For your customer (Live)  For fault tolerance (LPT)  For yourself (Andere Testumgebungen) http://www.amazon.de/gp/reader/B0050 47 3D1TY/ref=sib_dp_kd#reader-link © iteratec
  42. 42. Performance-Messumgebung WebPagetest „Portal“ extern intern WPTMonitor WPTMonitor WPTServer1 WPTServer2 WPT-Server Agent 1 Agent 2 Agent 1 Agent10 Agent 1 Agent 4 (IE Messung) (FF Messung) (Alle Browser) (Alle Browser) (IE, FF, Chrome) (IE, FF, Chrome) automatisch LPT Umgebung Automatisch/Einzelmessung QA Umgebung Live Umgebung Automatisch / Einzelmessung Develop Umgebung 48 © iteratec
  43. 43. Performance-Messumgebung Real User Monitoring Browser DSLAM Internet PC JavaScript Mess-Script AssetServer FW LB Grap hite AssetServer 49 © iteratec
  44. 44. Lasttestumgebung Tool-Klassen  Toolklassen  Synth. http-Request-Last (Apache Bench, JMeter, Silk Performer)  capture replay von realem Traffic (JMeter, Silk Performer, LoadRunner)  simulierte Browser (XLT auf Basis von HTMLunit)  ferngesteuerte Browser (Soke)  ferngesteuerte Rechner (viele WinRunner)  Massentest durch viele Menschen  TradeOff  Hardware-Aufwand  Pflege-Aufwand  Realitätstreue 51 © iteratec
  45. 45. Lasttestumgebung Lasttest auf der Basis von HTTP-Requests AS Browser Browser Lasttest-Tool (muss Logik im DSLAM PC Internet Browser nachstellen) PAProxy FW LB AS AS PAProxy AS Browser AS DSLAM Browser AS 52 © iteratec
  46. 46. Lasttestumgebung Simulierte Browser in Xceptance Load Test (XLT) Xceptance Load Test AS HTMLunit PAProxy HTMLunit PC Internet FW LB AS AS PAProxy AS HTMLunit AS HTMLunit AS 53 © iteratec
  47. 47. Lasttestumgebung Überblick über die Gesamtlandschaft jenkins xltmaster-01 xltmaster-02 100-500 Lastgeneratoren (8 core, 16 GB RAM) Prelive-cluster LoadBalancer LPT SAN … Product P13N Order PA-Proxy Live KPI Graphite PA-Proxy Auth SAN Product PA-Proxy P13N Order PA-Proxy Auth SAN … Product PA-Proxy P13N Order Auth PA-Proxy LoadBalancer … LoadBalancer Logging Splunk 56 © iteratec
  48. 48. Lastumgebung Kosten  Lasttests laufen selten 24*7 Typisches Thema für die Cloud  1. Ansatz: Amazon EC2  Kann alles  m3.2xlarge : 0,99 $ / Stunde  500 Agenten ~500 $ / Stunde  2. Ansatz: Digital Ocean  KISS  Einfach nutzbare REST-API  $160 Plan : 0,238 $ / Stunde  500 Agenten : ~119 $ / Stunde  Kundenansturm führt immer mal wieder zu Kapazitätsengpässen 57 © iteratec
  49. 49. Agenda  Erschlagen vom eigenen Erfolg  Herausforderungen  Fahrplan im Lhotse-Kontext zu entspannten Live-Gängen  Definition von Performance-/Lastanforderungen  Konzeption geeigneter Performance-Messungen und Lasttests  Aufbau einer passenden Umgebung  Regelmäßige Durchführung und Auswertung  Sizing der Systeme auf Basis von Lasttestergebnissen  Erfahrungen und Ergebnisse in der Praxis 58 © iteratec
  50. 50. Auswertung von Lasttests Auswertungen jenkins 1.XLT-Report xltmaster-01 xltmaster-02 500 Lastgeneratoren (8 core, 16GB RAM) Prelive-cluster 3.RessourcenMonitoring LPT SAN … Product PA-Proxy P13N Order PA-Proxy Auth SAN Product PA-Proxy P13N Order LoadBalancer 2.(Profiling) Log Live KPI Graphite 3.Graphite-Graph PA-Proxy Auth SAN … Product PA-Proxy P13N Order Auth PA-Proxy LoadBalancer … LoadBalancer 1.Antwortzeiten Logging Splunk 59 2.Splunk-Report © iteratec
  51. 51. Auswertung von Lasttests 1 XLT-Report  Durchsatz (Hits/s)  Durchsatz  User (Laufzeitprobleme ?)  Aktionen  Fehleranteil  Seitenladezeiten  Durchsatz / Aktion  Requests (Antwortzeiten, zeitlicher Verlauf)  Custom Timer (Auftreten von speziellen Fehlern, Detaillaufzeiten)  External  Error Data (Externe Laufzeiten) and Event (Fehlerbilder, Fehlerursachen)  Agents (Agent-Auslastung, Validität Messergebnisse) 60 © iteratec
  52. 52. Auswertung von Lasttests 1 XLT-Report : Typische Fehlerbilder  Verlängerung der Laufzeiten lässt Anzahl simulierter User überproportional steigen 61 © iteratec
  53. 53. Auswertung von Lasttests 1 XLT-Report : Typische Fehlerbilder  Stau auf der Datenautobahn Erwartete Kurve 62 © iteratec
  54. 54. Auswertung von Lasttests 1 XLT-Report : Typische Fehlerbilder  Einbruch nach Erreichen einer Lastgrenze = Überlast 63 © iteratec
  55. 55. Auswertung von Lasttests 1 XLT-Report : Typische Fehlerbilder  zunehmende Anzahl Timeouts (graue Spikes) lässt durchschnittliche Laufzeit (blaue Kurve) kontinuierlich steigen 64 © iteratec
  56. 56. Die vertikale Systemarchitektur Herausforderung: Verursacher identifizieren  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 Tracking ELCH Auth After Sales User Order Personalisation (P13N) Product Search & Navigation (SAN) Shoppages Shopoffice Frontend-Integration Daten-Integration 66 © iteratec
  57. 57. Auswertung von Lasttests 2 Splunk-Report  Dashboard  Client  Backend Request Laufzeiten  Aufteilung  Welches nach PageTag System ist für Laufzeitprobleme verantwortlich ? 68 © iteratec
  58. 58. Lasttestumgebung Ermittlung der Verursacher von Laufzeitproblemen in Splunk AS Browser PAProxy Browser Internet DSLAM FW LB AS PAProxy PC AS client Browser Splunk ( DSLAM Field Browser AS Extraktoren, Suchen, Dashboards) Backend AS Tomcat access DB.log AS 69 © iteratec
  59. 59. Auswertung von Lasttests 3. Graphite-Graphen  Rubriken für Ressourcenauslastung  CPU  Platten-IO  RAM  Netzwerk-IO  Plattform (Tomcat Threadpool, Java GC)  Anwendung  Verlinkung Jenkins-Job  Graphoo Dashboards  Details zur Ressourcenauslastung aller Maschinen in der Umgebung  Übersichts-Dashboard zu Performance- und Lasttests  Graphoo = eigene Rails-Anwendung zur dynamischen Generierung der Dashboards mit Graphite-Grafiken auf Basis des aktuellen Inventory der Umgebung 71 © iteratec
  60. 60. Auswertung von Lasttests 3. Graphite-Graphen : Low Level Sicht auf Maschinen-Ressourcen  Graphite Dashboard 72 © iteratec
  61. 61. Auswertung von Lasttests 3. Graphite-Graphen : High Level Sichten  Sicht auf Systeme (Vertikalen)  Logische Sicht auf Gesamtshop 73 © iteratec
  62. 62. Agenda  Erschlagen vom eigenen Erfolg  Herausforderungen  Fahrplan im Lhotse-Kontext zu entspannten Live-Gängen  Definition von Performance-/Lastanforderungen  Konzeption geeigneter Performance-Messungen und Lasttests  Aufbau einer passenden Umgebung  Regelmäßige Durchführung und Auswertung  Sizing der Systeme auf Basis von Lasttestergebnissen  Erfahrungen und Ergebnisse in der Praxis 75 © iteratec
  63. 63. Sizing der Systeme auf Basis von Lasttestergebnissen Vorgehen 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 ( live Re ssourcenbedarf (live )  Re ssourcen(Testumgebung ) * ZiellastTest ) ) * Re ssourcenauslastungsgrad ((Test)) Last ( Re ssourcenauslastungsgrad live 76 © iteratec
  64. 64. Agenda  Erfahrungen und Ergebnisse in der Praxis 78 © iteratec
  65. 65. Erfahrungen und Ergebnisse in der Praxis  Zahlen  Kontinuierliche 6 Lasttests seit 18 Monaten Ziel-Umgebungen, davon 3 für Lasttests genutzt  Je Umgebung zwischen 50 und 200 VM  Bis zu 500 VM‘s als Lastgeneratoren  3-8 Lasttestläufe pro Tag  5-50 GByte Ergebnisdaten pro Lasttestlauf  100-150 Metriken pro VM pro Minute  100-300 GByte tägliches Log-Volumen aus Lasttests 79 © iteratec
  66. 66. Erfahrungen und Ergebnisse in der Praxis  Zahlen  Live-Gang und alle vorherigen Meilensteine erfolgreich bewältigt Status Meilenstein Erwartet Ziel Nachgewiesen  Mitarbeiter-Shop 5 PI/s 50 PI/s 80 PI/s  Closed Alpha 25 PI/s 150 PI/s 180 PI/s  Live Beta 100 PI/s 350 PI/s 362 PI/s  Go-Live (Minimum Viable Product) 500 PI/s 750 PI/s 804 PI/s 80 © iteratec
  67. 67. Erfahrungen und Ergebnisse in der Praxis Lessons learned  Ohne smarte Ziele geht es nicht.   M = Messbar  A = Akzeptiert  R = Realistisch   S = Spezifisch T = Terminiert Zielerreichung laufend kommunizieren und visualisieren  Dashboard 82 © iteratec
  68. 68. Erfahrungen und Ergebnisse in der Praxis Dashboard I (agiler Start)  Arbeitsstand für alle sichtbar visualisieren: Dashboard 83 © iteratec
  69. 69. Erfahrungen und Ergebnisse in der Praxis Dashboard II 84 © iteratec
  70. 70. Erfahrungen und Ergebnisse in der Praxis Lessons learned  Ohne smarte Ziele geht es nicht.   M = Messbar  A = Akzeptiert  R = Realistisch   S = Spezifisch 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 85 © iteratec
  71. 71. Probleme treten nicht dort auf, wo man sie erwartet Beispiel SSL-Zertifikate  Langsame Zertifikate  Insgesamt 548 + 526 = 1.074 ms für die Prüfung der Zertifikats- Chain 91 © iteratec
  72. 72. Probleme treten nicht dort auf, wo man sie erwartet Beispiel SSL-Zertifikate  Schnelle Zertifikate  Nur noch 225 + 51 = 276 ms für die Prüfung der ZertifikatsChain  Ersparnis: fast 800 ms 92 © iteratec
  73. 73. Probleme treten nicht dort auf, wo man sie erwartet Beispiel SSL-Zertifikate  Auswirkungen auf das Laden der Homepage : ca. 700 ms 93 © iteratec
  74. 74. Erfahrungen und Ergebnisse in der Praxis Aufgedeckte Performance-/Skalierbarkeitsprobleme (lila) AS Browser PAProxy Browser DSLAM Internet FW LB AS PAProxy PC AS Browser FW DSLAM Browser AS AssetServer LB AssetServer AS AS 104 © iteratec
  75. 75. Erfahrungen und Ergebnisse in der Praxis Entspannte Live-Gänge in Sachen Performance- und Lastverhalten sind keine Utopie 105 © iteratec
  76. 76. Ihre Fragen ? Kontakt: Uwe.Bessle@iteratec.de Iteratec GmbH 106 © iteratec
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×