More Related Content Similar to DevCon-2013-PerformanceSkalierbarkeit_UweBessle (20) DevCon-2013-PerformanceSkalierbarkeit_UweBessle1. 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
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
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
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
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
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
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
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
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
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
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
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