DevCon 2013 - Performance und Skalierbarkeit zum Anfassen und Nachmessen

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. 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.  Erschlagen
vom eigenen Erfolg
 Herausforderungen
 Fahrplan
im Lhotse-Kontext
zu entspannten Live-Gängen
 Erfahrungen
und Ergebnisse in der Praxis
5
© iteratec

4. Vom eigenen Erfolg erschlagen
DaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen
6

Quelle: http://de.dawanda.com/topic/2169/10130642
© iteratec

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. 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. 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. 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. 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. 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. 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. Herausforderungen im Lhotse-Kontext
Agiles Vorgehensmodell : Architektur entsteht „by the way“ ?!
14
© iteratec

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. 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. 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. 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. 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. 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. 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. 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. Performance-Anforderungen
„Wie schnell wollen / müssen wir sein?“
23
© iteratec

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. 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. 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. 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. Last-Anforderungen
„Wieviel müssen wir aushalten können?“
28
© iteratec

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. Definition von Lastanforderungen
Quellen für Anforderungen
 Seitenverteilung
aus dem Web-Tracking
30
© iteratec

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. Definition von Lastanforderungen
Betrachtungs-Zeitraum : Monatsverlauf
maßgebliches Ziel
für Lasttest
relevante Kennzahl
für Businessplan
32
© iteratec

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. 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. 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. 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. Konzeption Performance-Messungen
Real User Monitoring : Browser Navigation Timing API
39
© iteratec

36. Lasttests zur Überprüfung der Lastanforderungen
Typische Anforderung : Lineare Skalierbarkeit
Anzahl User
40
© iteratec

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. 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. 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. 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. 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. 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. Performance-Messumgebung
Real User Monitoring
Browser
DSLAM
Internet
PC
JavaScript
Mess-Script
AssetServer
FW
LB
Grap
hite
AssetServer
49
© iteratec

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. 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. 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. 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. 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. 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. 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. 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. Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
 Verlängerung
der Laufzeiten lässt Anzahl simulierter User
überproportional steigen
61
© iteratec

53. Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
 Stau
auf der Datenautobahn
Erwartete Kurve
62
© iteratec

54. Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
 Einbruch
nach Erreichen einer Lastgrenze = Überlast
63
© iteratec

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. 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. Auswertung von Lasttests
2 Splunk-Report
 Dashboard
 Client
 Backend Request Laufzeiten
 Aufteilung
 Welches
nach PageTag
System ist für Laufzeitprobleme verantwortlich ?
68
© iteratec

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. 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. Auswertung von Lasttests
3. Graphite-Graphen : Low Level Sicht auf Maschinen-Ressourcen
 Graphite
Dashboard
72
© iteratec

61. Auswertung von Lasttests
3. Graphite-Graphen : High Level Sichten

Sicht auf Systeme (Vertikalen)

Logische Sicht auf Gesamtshop
73
© iteratec

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. 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. Agenda
 Erfahrungen
und Ergebnisse in der Praxis
78
© iteratec

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. 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. 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. Erfahrungen und Ergebnisse in der Praxis
Dashboard I (agiler Start)
 Arbeitsstand
für alle sichtbar visualisieren: Dashboard
83
© iteratec

69. Erfahrungen und Ergebnisse in der Praxis
Dashboard II
84
© iteratec

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. 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. 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. Probleme treten nicht dort auf, wo man sie erwartet
Beispiel SSL-Zertifikate
 Auswirkungen
auf das Laden der Homepage : ca. 700 ms
93
© iteratec

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. Erfahrungen und Ergebnisse in der Praxis
Entspannte Live-Gänge in Sachen Performance- und
Lastverhalten sind keine Utopie
105
© iteratec

76. Ihre Fragen ?
Kontakt: Uwe.Bessle@iteratec.de
Iteratec GmbH
106
© iteratec