DevCon-2013-PerformanceSkalierbarkeit_UweBessle

Effektiver Einsatz von Performance-Messungen und Lasttests

zur Optimierung der Performance und Skalierbarkeit einer

großen eCommerce Plattform

8. November 2013

[email protected]

Performance und Skalierbarkeit zum

Anfassen und Nachmessen

© iteratec

3

Funktionalität

Angemessenheit, Richtigkeit, Interoperabilität, Sicherheit,

Ordnungsmäßigkeit

Zuverlässigkeit

Reife, Fehlertoleranz, Wiederherstellbarkeit

Benutzbarkeit

Verständlichkeit, Erlernbarkeit, Bedienbarkeit, Attraktivität

Effizienz

Zeitverhalten, Verbrauchsverhalten

Wartbarkeit/Änderbarkeit

Analysierbarkeit, Modifizierbarkeit, Stabilität, Testbarkeit

Übertragbarkeit

Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit

Anforderungen an IT-SystemeKlassifizierung nach ISO/IEC 9126 / 25000 bzw. DIN 66272

© iteratec

5

Erschlagen vom eigenen Erfolg

Herausforderungen im Lhotse-Kontext

Fahrplan zu entspannten Live-Gängen

Erfahrungen und Ergebnisse in der Praxis

© iteratec

6

Vom eigenen Erfolg erschlagenDaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen

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

© iteratec

7

Vom eigenen Erfolg erschlagenTelekom Mobilfunkseite durch iPhone5 Andrang

Quelle: http://www.heise.de/mac-and-i/meldung/iPhone-Vorbestellung-ueberlastet-Telekom-1708303.html

14.09.2012

© iteratec

8

Vom eigenen Erfolg erschlagenRockstar Spieleserver : Probleme beim Start von Online-GTA-5

Quelle: http://www.onlinewelten.com/games/gta-online/news/server-ueberlastet-probleme-start-online-gta-5-update-rockstar-aeussert-123409/

01.10.2013

© iteratec

9

Vom eigenen Erfolg erschlagenGovData: www.daten-deutschland.de vom Start weg überlastet

Quelle: http://www.computerwoche.de/a/datenportal-der-bundesregierung-startet-holprig,2533210

20.02.2013

© iteratec

10

Vom eigenen Erfolg erschlagenhealthcare.gov : Auch drei Wochen nach dem Start noch ein Desaster

Quelle: http://www.tagesschau.de/ausland/usa612.html

21.10.2013

© iteratec

11

Agenda



Vertikale Systemarchitektur

Agiles Vorgehensmodell im Entwicklungsprozess

Auch die Cloud ist kein Allheilmittel

Steigende Anforderungen im Projektverlauf



© iteratec

12

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)

LhotseEckpunkte

© iteratec

13

RESTful Architektur1

Shared Nothing alsArchitekturprinzip

2

Vertikaler Systemschnitt3

Zentrale Verantwortlichkeit fürDaten & Datenversor-gungsprozesse

4

Buy when non coreA

Gemeinsame BasistechnologienB

Macro-Architektur

Micro-Architektur

Shop

offic

e

Shop

page

s

Sear

ch&

Nav

igat

ion

(SAN

)

Prod

uct

Pers

onali

satio

n(P

13N

)

Ord

er

Use

r

Trac

king

Auth

Afte

rSale

s

ELCH

Frontend-Integration

Daten-Integration

Herausforderungen im Lhotse-KontextVertikale Systemarchitektur : Viele separate Systeme

© iteratec

14

Herausforderungen im Lhotse-KontextAgiles Vorgehensmodell : Architektur entsteht „by the way“ ?!

© iteratec

15


Grundidee:

Einsatz von

Standardkomponenten zur

Lastverteilung (Load-Balancer)

+ horizontale Skalierbarkeit der

Anwendungskomponenten

+ dynamisches Buchen

zusätzlicher Ressourcen in der

Cloud

= Lastprobleme einfach gelöst

Wozu brauche ich Lasttests, ich habe doch die Cloud ?

Internet

Firewall

LoadBalancer

Web-Server

Web-Server

App-Server

App-Server

LoadBalancer

App-Server

Datenbank

Auth(LDAP)

© iteratec

16

Herausforderungen im Lhotse-KontextZielsetzung: Horizontale Skalierung

Internet

Firewall

LoadBalancer

Web-Server

Web-Server

App-Server

App-Server

LoadBalancer

App-Server

Datenbank

Auth(LDAP)

Web-Server

App-Server

Web-Server

App-Server

© iteratec

17


Theory meets Reality

typische Bottlenecks:

alles was zentral ist

RZ-Anbindung,

Firewall,

zentraler Load-Balancer,

zentrale Datenbank,

zentraler Authentication

Server (LDAP)

typisches Problem:

Implementierungsfehler

hebeln Skalierbarkeit aus

Architektur-Komponenten ohne horizontale Skalierbarkeit

Internet

Firewall

LoadBalancer

Web-Server

Web-Server

App-Server

App-Server

LoadBalancer

App-Server

Datenbank

Auth(LDAP)

Web-Server

App-Server

Web-Server

App-Server

© iteratec

18


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

Steigende Anforderungen im Projektverlauf

© iteratec

19


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

© iteratec

20

Performance- und Lastanforderungen

PC

DSLAM

Browser

Browser

Browser

Browser

DSLAM

Internet FW LB

PA-Proxy

PA-Proxy

AS

AS

AS

AS

AS

AS

Es geht immer irgendwie um Antwortzeiten, aber ...

© iteratec

21

PA-Proxy

DSLAM

Browser

AS

AS

Browser

Browser

AS

AS

Performance- und LastanforderungenPerformance

PC

DSLAMBrowser Internet FW LB

PA-Proxy

AS

AS

Seitenladezeit fürBenutzer im Client

© iteratec

22

Performance- und LastanforderungenLast

PC

DSLAM

Browser

Browser

Browser

Browser

DSLAM

Internet FW LB

PA-Proxy

PA-Proxy

AS

AS

AS

AS

AS

AS

Veränderung derAntwortzeiten unter

Last

© iteratec

23

Performance-Anforderungen

„Wie schnell wollen / müssen wir sein?“

© iteratec

24

Performance-AnforderungenAnalyse bestehender Methoden und Kriterien

0 1 2 3 4 5 n

Ladezeit (s)

gut

schlecht

Kunden-zufriedenheit

Google-Analytics

0 0,5 1 1,5 n

Ladezeit (s)

-20%

Traffic

20%

40%

60%

80%

100%

120%

Google Suchtrefferseite*

*http://glinden.blogspot.de/2006/11/marissa-mayer-at-web-20.html

0 T 4T Ladezeit

Zufriedenheit

frustrated

tolerating

satisfied

Default threshold: T = 4 sec, Ableitung eines Index 0-1

APDEX*

Strangeloop-Studie*

* http://apdex.org/index.php/about/* http://www.strangeloopnetworks.com/web-performance-infographics/ tml

© iteratec

25

Performance-AnforderungenUsability-Test: Wie zufrieden sind Benutzer mit der Ladezeit?

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

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

3. Iteration

2. Iteration

1. Iteration

Ladezeit bei der75% der Userzufrieden sind

Ladezeit bei der100% der Userzufrieden sind

Erwartungen wachsen mit der

Anzahl der Besuche

© iteratec

26

Performance-AnforderungenUsability-Test: Wie zufrieden sind Benutzer mit der Ladezeit?

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

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

Zufriedenheitmit Ladezeit

Ladezeit (s)

Seitentyp 1 1. It

Seitentyp 2 1. It.

Seitentyp 3 3. It

Seitentyp 3 1. It

Seitentyp 4 1. It

Seitentyp 5 1. It

© iteratec

27

Performance-AnforderungenCustomer Satisfaction Index (CSI)

Einzelzufriedenheiten

GewichtungsfaktorSeitenart

GewichtungsfaktorTageszeit

GewichtungsfaktorBrowserverteilung

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)

?

GewichtungsfaktorXYZ

Ladezeit -> Zufriedenheit

90%

© iteratec

28

Last-Anforderungen

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

© iteratec

29

Last-anforderungen

Last-anforderungen

Interviews• Business Development• Fachabteilung• Betrieb• ...

Fachliche Planzahlen• Business Case• Benchmarking

(Wettbewerber)

Nutzung desAltsystem

• Web-Tracking (fachlicheKennzahlen) !

• Monitoring (technischeKennzahlen)

Definition von LastanforderungenWoher kommen konkrete Anforderungen ?

© iteratec

30

Seitenverteilung aus dem Web-Tracking

Definition von LastanforderungenQuellen für Anforderungen

© iteratec

31

Definition von LastanforderungenBetrachtungs-Zeitraum : Typische Tageskurve

0

100.000

200.000

300.000

400.000

500.000

600.000

700.000

800.000

900.000

1.000.000

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

Page views / h

© iteratec

32

Definition von LastanforderungenBetrachtungs-Zeitraum : Monatsverlauf

relevante Kennzahlfür Businessplan

maßgebliches Zielfür Lasttest

© iteratec

35

Agenda










© iteratec

36

Messpunkt Server Backbone Last Mile Client Browser FrontendLogik

Einfluss-faktoren

• Standort• Caching• CDN• Auslastung• Backend-

Latenzen• ….

• Anbindung • Bandbreite• Verbindungs-

art (DSL,UMTS, …)

• Hard- undSoftwareAusstattung

• AllgemeinePerformance

• Hersteller• Version

• Codequalität

Backbone-Messungen Client-Messungen

Konzeption Performance-Messungen

Anforderungen an Messmethode

„Realistisch“?

Soll: Wie performt die Applikation beim Kunden?

© iteratec

37

Konzeption Performance-MessungenSynthetische Messungen Real User Monitoring

Synthetische MessungSynthetische Messung

Pro

• Reproduzierbar• Steuerbar• Klare Signale

Pro

• Reproduzierbar• Steuerbar• Klare Signale

Contra

• Bilden nicht die Realität ab• Kein Blick auf den Kunden• Keine Verfügbarkeitsaussagen

Contra

• Bilden nicht die Realität ab• Kein Blick auf den Kunden• Keine Verfügbarkeitsaussagen

Real User MonitoringReal User Monitoring

Pro

• Zeigen was beim Kundenankommt

• Mengen-/Verfügbarkeitsaussagen

Pro

• Zeigen was beim Kundenankommt

• Mengen-/Verfügbarkeitsaussagen

Contra

• Nicht reproduzierbar• Fehlsignale durch schlechte

Kundenanbindungen

Contra

• Nicht reproduzierbar• Fehlsignale durch schlechte

Kundenanbindungen

Nicht entweder/oder sondern sowohl als auch

© iteratec

38

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?

Messzeitpunkt:

Welches ist der für Nutzer relevante Zeitpunkt eines “Seite fertig geladen” Gefühls?

© iteratec

39

Konzeption Performance-MessungenReal User Monitoring : Browser Navigation Timing API

© iteratec

40

Lasttests zur Überprüfung der LastanforderungenTypische Anforderung : Lineare Skalierbarkeit

Anzahl User

© iteratec

43

Messung mit linear steigender Last

grün: linearer Bereich, Antwortzeit ist konstant,

auch bei steigender Last

gelb: nichtlinearer Bereich, Antwortzeiten beginnen zu steigen,

orange: Sättigung, Antwortzeiten steigen synchron zur Last

rot: Überlast, Antwortzeiten steigen stärker als die Last, der

Durchsatz verringert sich mit weiterer Erhöhung der Last,

Lasttests zur Überprüfung der LastanforderungenBeispiel: Durchsatzmessung in Abhängigkeit von der Last

Lastkurve bei idealemSystemverhalten

(lineare Skalierbarkeit)

© iteratec

44

Realistische Lasttests

möglichst viele der Requests, die in der Realität auftauchen

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

Lasttests zur Überprüfung der LastanforderungenAnforderungen an Lasttests

modellierter Lastanteil 90% 95% 98% 99%

abzubildende UseCases 5-10 10-20 25-50 50-100

© iteratec

45

Agenda










© iteratec

46

Real User Monitoring

Aufbau einer passenden UmgebungLPT-Testumgebung

Develop-ci(CI)

Develop(QA)

LPT(Last+Perf.

Test)

Prelive(Abnahme)

Live

WebPageTest Performance-Messungen

Continuous Delivery (Release Pipeline)

XLT Lasttests

© iteratec

47

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)

Aufbau einer passenden UmgebungSizing der LPT-Testumgebung

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

http://www.amazon.de/gp/reader/B00503D1TY/ref=sib_dp_kd#reader-link

© iteratec

48

Performance-MessumgebungWebPagetest

WPT-Server

Agent 1(IE, FF, Chrome)

Agent 4(IE, FF, Chrome)

Server1WPT-

Server1

Agent 1(IE Messung)

Agent 2(FF Messung)

Agent 1(Alle Browser)

„Portal“

automatisch Automatisch/Einzelmessung

DevelopUmgebung

Automatisch / Einzelmessung

intern

WPT-MonitorWPT-

Monitor

Server2WPT-

Server2

WPT-MonitorWPT-

Monitor

extern

Agent10(Alle Browser)

LiveUmgebung

QAUmgebung

LPTUmgebung

© iteratec

49

Performance-MessumgebungReal User Monitoring

PC

DSLAMBrowser Internet

GraphiteFW LB

Asset-Server

Asset-Server

JavaScriptMess-Script

© iteratec

51

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

LasttestumgebungTool-Klassen

© iteratec

52

LasttestumgebungLasttest auf der Basis von HTTP-Requests

PC

DSLAM

Browser

Browser

Browser

Browser

DSLAM

Internet FW LB

PA-Proxy

PA-Proxy

AS

AS

AS

AS

AS

AS

Lasttest-Tool(muss Logik im

Browser

nachstellen)

© iteratec

53

Xceptance Load Test

LasttestumgebungSimulierte Browser in Xceptance Load Test (XLT)

PC

HTMLunit

Internet FW LB

PA-Proxy

PA-Proxy

AS

AS

AS

AS

AS

AS

HTMLunit

HTMLunit

HTMLunit

© iteratec

56

LasttestumgebungÜberblick über die Gesamtlandschaft

Prelive-cluster

100-500 Lastgeneratoren (8 core, 16 GB RAM)

jenkins

xltmaster-01 xltmaster-02

LoadBalancer

PA-Proxy PA-Proxy

Au

th

Ord

er

P1

3N

Pro

du

ct

…

SA

N

LPT

LoadBalancer

PA-Proxy PA-Proxy

Au

th

Ord

er

P1

3N

Pro

du

ct

…

SA

N

Live

LoadBalancer

PA-Proxy PA-Proxy

Au

th

Ord

er

P1

3N

Pro

du

ct

…

SA

N

Graphite Splunk

LoggingKPI

© iteratec

57

Lasttests laufen selten 24*7Typisches 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

LastumgebungKosten

© iteratec

58

Agenda










© iteratec

59

Auswertung von LasttestsAuswertungen

Prelive-cluster

500 Lastgeneratoren (8 core, 16GB RAM)

jenkins

xltmaster-01 xltmaster-02

LoadBalancer

PA-Proxy PA-Proxy

Au

th

Ord

er

P1

3N

Pro

du

ct

…

SA

N

LPT

LoadBalancer

PA-Proxy PA-Proxy

Au

th

Ord

er

P1

3N

Pro

du

ct

…

SA

N

Live

LoadBalancer

PA-Proxy PA-Proxy

Au

th

Ord

er

P1

3N

Pro

du

ct

…

SA

N

Graphite Splunk

LoggingKPI

1.XLT-Report

2.Splunk-Report3.Graphite-Graph

1.Antwortzeiten

2.(Profiling) Log3.Ressourcen-

Monitoring

© iteratec

60

Durchsatz (Hits/s)

Durchsatz User (Laufzeitprobleme ?)

Aktionen

Fehleranteil

Seitenladezeiten

Durchsatz / Aktion

Requests (Antwortzeiten, zeitlicher Verlauf)

Custom Timer (Auftreten von speziellen Fehlern,

Detaillaufzeiten)

External Data (Externe Laufzeiten)

Error and Event (Fehlerbilder, Fehlerursachen)

Agents (Agent-Auslastung, Validität Messergebnisse)

Auswertung von Lasttests1 XLT-Report

© iteratec

61

Verlängerung der Laufzeiten lässt Anzahl simulierter User

überproportional steigen

Auswertung von Lasttests1 XLT-Report : Typische Fehlerbilder

© iteratec

64

zunehmende Anzahl Timeouts (graue Spikes) lässt

durchschnittliche Laufzeit (blaue Kurve) kontinuierlich steigen


© iteratec

66

Shopoff

ice

Shoppag

es

Searc

h&

Navi

gation

(SA

N)

Pro

duct

Pers

onalis

ation

(P13N

)

Ord

er

User

Tra

ckin

g

Auth

Aft

er

Sale

s

ELC

H

Frontend-Integration

Daten-Integration

Die vertikale SystemarchitekturHerausforderung: Verursacher identifizieren

Der Seitenrahmen und der Hauptinhalt kommtaus dem product-System

Der Miniwarenkorb liefert das order-System Die Navigation wird vom san-System

bereitgestellt Die Produktempfehlungen stammen aus dem

p13n-System

© iteratec

68

Dashboard

Client Backend Request Laufzeiten

Aufteilung nach PageTag

Welches System ist für Laufzeitprobleme verantwortlich ?

Auswertung von Lasttests2 Splunk-Report

© iteratec

69

LasttestumgebungErmittlung der Verursacher von Laufzeitproblemen in Splunk

PC

DSLAM

Browser

Browser

Browser

Browser

DSLAM

Internet FW LB

PA-Proxy

PA-Proxy

AS

AS

AS

AS

AS

AS

Splunk(Field Extraktoren,

Suchen,

Dashboards)

client

Backend

Tomcataccess

DB.log

© iteratec

71

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

Auswertung von Lasttests3. Graphite-Graphen

© iteratec

72

Graphite Dashboard

Auswertung von Lasttests3. Graphite-Graphen : Low Level Sicht auf Maschinen-Ressourcen

© iteratec

73

Auswertung von Lasttests3. Graphite-Graphen : High Level Sichten

Sicht auf Systeme (Vertikalen) Logische Sicht auf Gesamtshop

© iteratec

76

1. Messung der Spitzenlast im Lasttest

2. Messung der Ressourcenauslastung während des Lasttests

3. Messung der zugeordneten Ressourcen in der Lastumgebung

4. Vorgabe der Ziellast

5. Vorgabe der Ressourcenauslastung bei Ziellast

Lastreserve

Ausfallreserve

6. Vorgaben zum Server-/VM-Zuschnitt

minimale Anzahl Server/VM‘s pro Komponente

Ressourcen pro Server/VM

7. Extrapolation der benötigten Ressourcen in der Zielumgebung

Sizing der Systeme auf Basis von LasttestergebnissenVorgehen

)(

)(

)(

)(

Re

Re**)()( ReRe

live

Test

Test

live

radslastungsgssourcenau

radslastungsgssourcenau

Last

ZiellastngTestumgebulive ssourcendarfssourcenbe

© iteratec

79

Kontinuierliche Lasttests seit 18 Monaten

6 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

Erfahrungen und Ergebnisse in der PraxisZahlen

© iteratec

80

Live-Gang und alle vorherigen Meilensteine erfolgreich

bewältigt

Erfahrungen und Ergebnisse in der PraxisZahlen

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

© iteratec

82

Ohne smarte Ziele geht es nicht.

S = Spezifisch

M = Messbar

A = Akzeptiert

R = Realistisch

T = Terminiert

Zielerreichung laufend kommunizieren und visualisieren

Dashboard

Erfahrungen und Ergebnisse in der PraxisLessons learned

© iteratec

83

Arbeitsstand für alle sichtbar visualisieren: Dashboard

Erfahrungen und Ergebnisse in der PraxisDashboard I (agiler Start)

© iteratec

85

Ohne smarte Ziele geht es nicht.

S = Spezifisch

M = Messbar

A = Akzeptiert

R = Realistisch

T = Terminiert

Zielerreichung laufend kommunizieren und visualisieren

Dashboard

Die Probleme treten meist nicht dort auf, wo man sie vermutet.

Lasttest so dicht wie möglich an der Wirklichkeit gestalten

BlackBox Test

Erfahrungen und Ergebnisse in der PraxisLessons learned

© iteratec

91

Langsame Zertifikate

Insgesamt 548 + 526 = 1.074 ms für die Prüfung der Zertifikats-

Chain

Probleme treten nicht dort auf, wo man sie erwartetBeispiel SSL-Zertifikate

© iteratec

92

Schnelle Zertifikate

Nur noch 225 + 51 = 276 ms für die Prüfung der Zertifikats-

Chain

Ersparnis: fast 800 ms


© iteratec

104

Erfahrungen und Ergebnisse in der PraxisAufgedeckte Performance-/Skalierbarkeitsprobleme (lila)

PC

DSLAM

Browser

Browser

Browser

Browser

DSLAM

Internet FW LB

PA-Proxy

PA-Proxy

AS

AS

AS

AS

AS

AS

FW LB

Asset-Server

Asset-Server

DevCon-2013-PerformanceSkalierbarkeit_UweBessle

Technology

Transcript of DevCon-2013-PerformanceSkalierbarkeit_UweBessle