SlideShare ist ein Scribd-Unternehmen logo
1 von 76
Downloaden Sie, um offline zu lesen
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
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
 Erschlagen

vom eigenen Erfolg

 Herausforderungen
 Fahrplan

im Lhotse-Kontext

zu entspannten Live-Gängen

 Erfahrungen

und Ergebnisse in der Praxis

5
© iteratec
Vom eigenen Erfolg erschlagen
DaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen

6


Quelle: http://de.dawanda.com/topic/2169/10130642

© iteratec
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
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/
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
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
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
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
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
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:


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

23
© iteratec
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
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
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
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
Last-Anforderungen

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

28
© iteratec
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
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.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
Definition von Lastanforderungen
Betrachtungs-Zeitraum : Monatsverlauf

maßgebliches Ziel
für Lasttest

relevante Kennzahl
für Businessplan

32
© iteratec
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
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
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
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
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 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
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
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
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
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
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
Performance-Messumgebung
Real User Monitoring

Browser

DSLAM

Internet

PC

JavaScript
Mess-Script

AssetServer
FW

LB

Grap
hite

AssetServer
49
© iteratec
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
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
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
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
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
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
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
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
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
 Verlängerung

der Laufzeiten lässt Anzahl simulierter User
überproportional steigen

61
© iteratec
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
 Stau

auf der Datenautobahn

Erwartete Kurve

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

nach Erreichen einer Lastgrenze = Überlast

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

Timeouts (graue Spikes) lässt
durchschnittliche Laufzeit (blaue Kurve) kontinuierlich steigen

64
© iteratec
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
Auswertung von Lasttests
2 Splunk-Report
 Dashboard
 Client

 Backend Request Laufzeiten

 Aufteilung
 Welches

nach PageTag

System ist für Laufzeitprobleme verantwortlich ?

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

Dashboard

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



Sicht auf Systeme (Vertikalen)



Logische Sicht auf Gesamtshop

73
© iteratec
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
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
Agenda

 Erfahrungen

und Ergebnisse in der Praxis

78
© iteratec
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
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
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
Erfahrungen und Ergebnisse in der Praxis
Dashboard I (agiler Start)
 Arbeitsstand

für alle sichtbar visualisieren: Dashboard

83
© iteratec
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 = 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
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
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
Probleme treten nicht dort auf, wo man sie erwartet
Beispiel SSL-Zertifikate
 Auswirkungen

auf das Laden der Homepage : ca. 700 ms

93
© iteratec
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
Erfahrungen und Ergebnisse in der Praxis

Entspannte Live-Gänge in Sachen Performance- und
Lastverhalten sind keine Utopie

105
© iteratec
Ihre Fragen ?

Kontakt: Uwe.Bessle@iteratec.de
Iteratec GmbH

106
© iteratec

Weitere ähnliche Inhalte

Ähnlich wie DevCon-2013-PerformanceSkalierbarkeit_UweBessle

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
 
Die unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles AnforderungsmanagementDie unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles AnforderungsmanagementThomas Moedl
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.QAware GmbH
 
Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8s
Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8sKontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8s
Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8sQAware GmbH
 
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
 
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
 
Selenium oder CBTA - Automatisierter Test von Weboberflächen im SAP Umfeld
Selenium oder CBTA - Automatisierter Test von Weboberflächen im SAP UmfeldSelenium oder CBTA - Automatisierter Test von Weboberflächen im SAP Umfeld
Selenium oder CBTA - Automatisierter Test von Weboberflächen im SAP UmfeldChristoph Menke
 
ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“QAware GmbH
 
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“OPEN KNOWLEDGE GmbH
 
Oracle Mobile Cloud Service im Einsatz
Oracle Mobile Cloud Service im EinsatzOracle Mobile Cloud Service im Einsatz
Oracle Mobile Cloud Service im EinsatzVolker Linz
 
Performance Day 2012 Performance on the Run
Performance Day 2012 Performance on the RunPerformance Day 2012 Performance on the Run
Performance Day 2012 Performance on the RunMarc Rieger
 
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...engelschall
 
Cloud – der nächste Schritt der Diagnose (German)
Cloud – der nächste Schritt der Diagnose (German)Cloud – der nächste Schritt der Diagnose (German)
Cloud – der nächste Schritt der Diagnose (German)KPIT
 
Warum Automatisierung der Dreh
Warum Automatisierung der DrehWarum Automatisierung der Dreh
Warum Automatisierung der DrehITOutcomes
 
Warum Automatisierung der Dreh und Angelpunkt eines erfolgreichen virtuellen ...
Warum Automatisierung der Dreh und Angelpunkt eines erfolgreichen virtuellen ...Warum Automatisierung der Dreh und Angelpunkt eines erfolgreichen virtuellen ...
Warum Automatisierung der Dreh und Angelpunkt eines erfolgreichen virtuellen ...ITOutcomes
 
Mit Performance-Modellierung Test- und Betriebskosten senken
Mit Performance-Modellierung Test- und Betriebskosten senkenMit Performance-Modellierung Test- und Betriebskosten senken
Mit Performance-Modellierung Test- und Betriebskosten senkenDynatrace
 
Lasttest auf Zuruf CloudTest On Demand
Lasttest auf Zuruf CloudTest On DemandLasttest auf Zuruf CloudTest On Demand
Lasttest auf Zuruf CloudTest On DemandSOASTA
 

Ähnlich wie DevCon-2013-PerformanceSkalierbarkeit_UweBessle (20)

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
 
Die unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles AnforderungsmanagementDie unendliche User Story - agiles Anforderungsmanagement
Die unendliche User Story - agiles Anforderungsmanagement
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8s
Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8sKontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8s
Kontinuierliches (Nicht)-Funktionales Testen von Microservices auf K8s
 
Net@night asp.net mvc
Net@night asp.net mvcNet@night asp.net mvc
Net@night asp.net mvc
 
DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
 
BizSpark goes Cloud
BizSpark goes CloudBizSpark goes Cloud
BizSpark goes Cloud
 
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
Auf gehts in die Cloud: „Das kann doch nicht so schwer sein!“
 
Selenium oder CBTA - Automatisierter Test von Weboberflächen im SAP Umfeld
Selenium oder CBTA - Automatisierter Test von Weboberflächen im SAP UmfeldSelenium oder CBTA - Automatisierter Test von Weboberflächen im SAP Umfeld
Selenium oder CBTA - Automatisierter Test von Weboberflächen im SAP Umfeld
 
ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“ROSIK Stammtisch „Clean Architecture“
ROSIK Stammtisch „Clean Architecture“
 
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
Auf geht‘s in die Cloud: „Das kann doch nicht so schwer sein!“
 
Oracle Mobile Cloud Service im Einsatz
Oracle Mobile Cloud Service im EinsatzOracle Mobile Cloud Service im Einsatz
Oracle Mobile Cloud Service im Einsatz
 
Performance Day 2012 Performance on the Run
Performance Day 2012 Performance on the RunPerformance Day 2012 Performance on the Run
Performance Day 2012 Performance on the Run
 
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
Microservices - Architekturansatz mit grossen Herausforderungen und gewissen ...
 
Cloud – der nächste Schritt der Diagnose (German)
Cloud – der nächste Schritt der Diagnose (German)Cloud – der nächste Schritt der Diagnose (German)
Cloud – der nächste Schritt der Diagnose (German)
 
Definition of Ready
Definition of ReadyDefinition of Ready
Definition of Ready
 
Warum Automatisierung der Dreh
Warum Automatisierung der DrehWarum Automatisierung der Dreh
Warum Automatisierung der Dreh
 
Warum Automatisierung der Dreh und Angelpunkt eines erfolgreichen virtuellen ...
Warum Automatisierung der Dreh und Angelpunkt eines erfolgreichen virtuellen ...Warum Automatisierung der Dreh und Angelpunkt eines erfolgreichen virtuellen ...
Warum Automatisierung der Dreh und Angelpunkt eines erfolgreichen virtuellen ...
 
Mit Performance-Modellierung Test- und Betriebskosten senken
Mit Performance-Modellierung Test- und Betriebskosten senkenMit Performance-Modellierung Test- und Betriebskosten senken
Mit Performance-Modellierung Test- und Betriebskosten senken
 
Lasttest auf Zuruf CloudTest On Demand
Lasttest auf Zuruf CloudTest On DemandLasttest auf Zuruf CloudTest On Demand
Lasttest auf Zuruf CloudTest On Demand
 

DevCon-2013-PerformanceSkalierbarkeit_UweBessle

  • 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
  • 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
  • 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