Präsentation zum Thema Lasttests auf dem 11. Performance Meetup in Hamburg

1. 11. PerformanceMeetup
28. Mai 2013
Uwe.Bessle@iteratec.de
Effektiver Einsatz von Lasttests zur
Optimierung der Skalierbarkeit von
Web-Sites

2. © iteratec
2
Agenda
 Erschlagen vom eigenen Erfolg
 Beispiele aus der jüngeren Vergangenheit
 Auch die Cloud ist kein Allheilmittel
 Fahrplan zu entspannten Live-Gängen
 Erfahrungen und Ergebnisse in der Praxis

3. © iteratec
3
Vom eigenen Erfolg erschlagen
Telekom Mobilfunkseite durch iPhone5 Andrang
 Quelle: http://www.heise.de/mac-and-i/meldung/iPhone-Vorbestellung-ueberlastet-Telekom-1708303.html

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

5. © iteratec
5
Vom eigenen Erfolg erschlagen
GovData: www.daten-deutschland.de vom Start weg überlastet
 Quelle: http://www.computerwoche.de/a/datenportal-der-bundesregierung-startet-holprig,2533210

6. © iteratec
6
Agenda
 Erschlagen vom eigenen Erfolg
 Beispiele aus der jüngeren Vergangenheit
 Auch die Cloud ist kein Allheilmittel
 Fahrplan zu entspannten Live-Gängen
 Erfahrungen und Ergebnisse in der Praxis

7. © iteratec
7
Erschlagen vom eigenen Erfolg
 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)
Cache

8. © iteratec
8
Erschlagen vom eigenen Erfolg
Theory meets Reality
 typische Bottlenecks:
alles was zentral ist
 RZ-Anbindung,
 Firewall,
 zentraler Load-Balancer,
 zentraler Cache,
 zentrale Datenbank,
 zentraler Authentication
Server (LDAP)
 typisches Problem:
Implementierungsfehler
hebeln Skalierbarkeit aus
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)
Cache

9. © iteratec
9
Agenda
 Erschlagen vom eigenen Erfolg
 Fahrplan zu entspannten Live-Gängen
 Definition von Lastanforderungen
 Lasttests zur Überprüfung der Lastanforderungen
 Auswahl der passenden Tools
 Auswertung von Lasttests
 Sizing der Systeme auf Basis von Lasttestergebnissen
 Erfahrungen und Ergebnisse in der Praxis

10. © iteratec
10
Fachliche
Anforderung
Technische
Entsprechung
Betrachtungs-
Unterschied
Anzahl Besucher #User unangemeldete Besucher
Visits pro Monat #Session/h
Betrachtungs-Zeitraum,
Session-Timeout,
Bot-Session
PageView bzw.
PageImpression pro
Tag
Hit/s
Betrachtungs-Zeitraum,
statische Ressourcen,
AJAX-Requests,
Tracking-Requests,
API-Calls
Definition von Lastanforderungen
Typische Kennzahlen

11. © iteratec
11
 Generelle Empfehlung: Ausrichtung an den Business-
Anforderungen
 Business-Kennzahlen als Basis für die Definition der
Lastanforderungen verwenden
 Aber: Abweichungen zur technischen Sicht berücksichtigen
 Die Server müssen die technisch ankommende Last verkraften
 Richtigen Betrachtungszeitraum wählen
 technisch motivierte Lastkomponenten berücksichtigen
 Bot-Requests
 Statische Ressourcen
 AJAX-Calls
 Tracking-Requests
Definition von Lastanforderungen
Woran ausrichten

12. © iteratec
12
Definition von Lastanforderungen
Betrachtungs-Zeitraum : Typische Tageskurve

13. © iteratec
13
Definition von Lastanforderungen
Betrachtungs-Zeitraum : Monatsverlauf
relevante Kennzahl
für Businessplan
maßgebliches Ziel
für Lasttest

14. © iteratec
14
 Statische Ressourcen
 bis zu 100 Bilder, Javascript- und CSS-Dateien pro Seitenaufruf
Definition von Lastanforderungen
Übersehene Anforderungsbestandteile : Statische Ressourcen
MIME Type Requests▼
image 80
js 16
html 12
css 10
other 6
text 2
flash 0
 Lösungen
 auf CDN auslagern
 auf eigene Cookie-less Domain auslagern
 im Lasttest mit berücksichtigen (Last mit generieren)

15. © iteratec
15
 Woher kommen zusätzliche Requests?
 Google
 Microsoft Bing
 diverse andere Suchmaschinen
 automatisiertes Verfügbarkeits-Monitoring
 automatisiertes Performance-Monitoring
 Benchmarking der Wettbewerber
 Verlinkungen in sozialen Netzwerken
 ...
 Bots verursachen
 50% aller Sessions
 10% aller Seitenaufrufe
 1-click Sessions (Bot setzt keinen Cookie)
Definition von Lastanforderungen
Übersehene Anforderungsbestandteile : Bot-Requests

16. © iteratec
16
Definition von Lastanforderungen
Abgestuftes Vorgehen mit mehreren Meilensteinen

17. © iteratec
17
 Woher kommen konkrete Anforderungen ?
1. Ablösung Altsystem: Zahlen zur Nutzung des Altsystem
 Web-Tracking (fachliche Kennzahlen) !
 Monitoring (technische Kennzahlen)
Definition von Lastanforderungen
Quellen für Anforderungen

18. © iteratec
18
 Seitenverteilung aus dem Web-Tracking
Definition von Lastanforderungen
Quellen für Anforderungen

19. © iteratec
19
 Woher kommen konkrete Anforderungen ?
1. Ablösung Altsystem: Zahlen zur Nutzung des Altsystem
 Web-Tracking (fachliche Kennzahlen) !
 Monitoring (technische Kennzahlen)
2. neue Anwendungen:
 Business Case
 Benchmarking (Wettbewerber)
3. Interviews (Stakeholder: Fachabteilung, Betrieb, ...)
 haben oft nur allgemeine Ziele und wenig konkrete Vorstellungen
Definition von Lastanforderungen
Quellen für Anforderungen

20. © iteratec
20
Agenda
 Erschlagen vom eigenen Erfolg
 Fahrplan zu entspannten Live-Gängen
 Definition von Lastanforderungen
 Lasttests zur Überprüfung der Lastanforderungen
 Auswahl der passenden Tools
 Auswertung von Lasttests
 Sizing der Systeme auf Basis von Lasttestergebnissen
 Erfahrungen und Ergebnisse in der Praxis

21. © iteratec
21
1. Testarten
 Performance-Messung: Wie schnell ist das System ohne Last?
 Lasttest: Wie verhält sich das System unter Last?
 Stresstest: Wie kommt das System mit Überlastsituationen klar?
2. Umfang
 Komponenten-Lasttest: Lasttest einzelner Komponenten
 System-Lasttest: Lasttest des Gesamtsystems
3. Zielsetzungen
 Entwicklungs-Lasttest: Untersuchung des Lastverhaltens,
Identifikation von Engpässen
 Abnahme-Lasttest: Überprüfung der Zielerreichung bzgl.
Lastanforderungen
Lasttests zur Überprüfung der Lastanforderungen
Begriffsklärung

22. © iteratec
22
1. Testarten
 Performance-Messung: Wie schnell ist das System ohne Last?
 Lasttest: Wie verhält sich das System unter Last?
 Stresstest: Wie kommt das System mit Überlastsituationen klar?
2. Umfang
 Komponenten-Lasttest: Lasttest einzelner Komponenten
 System-Lasttest: Lasttest des Gesamtsystems
3. Zielsetzungen
 Entwicklungs-Lasttest: Untersuchung des Lastverhaltens,
Identifikation von Engpässen
 Abnahme-Lasttest: Überprüfung der Zielerreichung bzgl.
Lastanforderungen
Lasttests zur Überprüfung der Lastanforderungen
Begriffsklärung

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

24. © iteratec
24
 Messung mit linear steigender Last
Lasttests zur Überprüfung der Lastanforderungen
Beispiel: Durchsatzmessung in Abhängigkeit von der Last

25. © iteratec
25
 Messung mit linear steigender Last
Lasttests zur Überprüfung der Lastanforderungen
Beispiel: Durchsatzmessung in Abhängigkeit von der Last
Lastkurve bei idealem
Systemverhalten
(lineare Skalierbarkeit)

26. © iteratec
26
 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 Lastanforderungen
Beispiel: Durchsatzmessung in Abhängigkeit von der Last
Lastkurve bei idealem
Systemverhalten
(lineare Skalierbarkeit)

27. © iteratec
27
 Realistische Lasttests
 möglichst viele der Requests, die in der Realität auftauchen
 alle relevanten UseCases
 statische Ressourcen, AJAX-Calls, Tracking-Requests, …
 Mix der Requests (Häufigkeitsverteilung)
 Sessionlänge
 Abfolge der Requests
 Think-Time
 Datenvielfalt (Kategorien, Artikel, Suchbegriffe, Kunden, ...)
Lasttests zur Überprüfung der Lastanforderungen
Realistische Lasttests
modellierter Lastanteil 90% 95% 98% 99%
abzubildende UseCases 5-10 10-20 25-50 50-100

28. © iteratec
28
 Zufällige Lasttests
 Deterministische Szenarien haben weniger Aussagekraft
 testen nur ein konkretes Szenario und verbergen Fehler
 finden Fehler, die in der Realität so nicht vorkommen werden
 zufällige Testdaten, zufällige Session-Längen, zufällige Testschritt-
Reihenfolgen, zufällige Wartezeiten (Think Time), zufällige
Warenkorbgrößen
 Praxis
 Gewichtete Zufallsauswahl auf Basis relativer Häufigkeiten (CSV)
 Auswahl Suchbegriff aus den Top-3000 Suchbegriffen der Kunden
 Zufälliger Shuffle der Testschritt-Reihenfolge
 Think-Time zwischen Testschritten
Lasttests zur Überprüfung der Lastanforderungen
Zufällige Lasttests

29. © iteratec
29
 Regelmäßige Lasttests
 Lastziele werden nicht auf Anhieb erreicht
 neue Fehler machen bereits erreichtes zunichte
 Praxis
 Automatisierte Komponenten-Lasttest in der Build-Pipeline
 Automatisierte tgl. System-Lasttests + mehrfach individuell
gestartete Lasttests am Tage
 Automatisierte Abnahme-Lasttest in der Release-Pipeline
Lasttests zur Überprüfung der Lastanforderungen
Regelmäßige Lasttests

30. © iteratec
30
Lasttests zur Überprüfung der Lastanforderungen
Einordnung der Lasttests in die Build- und Release-Pipeline

31. © iteratec
31
Perfor-
mance Lasttest
Robust-
heit
System-LPT
Perfor-
mance Lasttest
Robust-
heit
Abnahme-LPT
Lasttests zur Überprüfung der Lastanforderungen
Einordnung der Lasttests in die Build- und Release-Pipeline
Perfor-
mance Lasttest
Komponenten-LPT

32. © iteratec
32
Agenda
 Erschlagen vom eigenen Erfolg
 Fahrplan zu entspannten Live-Gängen
 Definition von Lastanforderungen
 Lasttests zur Überprüfung der Lastanforderungen
 Auswahl der passenden Tools
 Auswertung von Lasttests
 Sizing der Systeme auf Basis von Lasttestergebnissen
 Erfahrungen und Ergebnisse in der Praxis

33. © iteratec
33
 Toolklassen
 synthetische http-Request-Last (ab, JMeter, Silk Performer)
 capture replay von realem Traffic (JMeter, Silk Performer,
LoadRunner)
 simulierte Browser (XLT)
 ferngesteuerte Browser (Soke)
 ferngesteuerte Rechner (viele WinRunner)
 gesteuerte Menschengruppe
 TradeOff
 Hardware-Aufwand  Pflege-Aufwand / Realitätstreue
Auswahl der passenden Tools
Tool-Klassen

34. © iteratec
34
Auswahl der passenden Tools
HW-Bedarf
Tool-Kategorie echte
User
echte
Browser
simulierte
Browser
HTTP-Traffic einfache
HTTP-
Lastsynthetisch capture /
replay
Realitätstreue max sehr
hoch
hoch mittel max gering
Pflegeaufwand min gering gering hoch mittel mittel
HW-Bedarf (für
Ziellast)
2-5.000
PC
1-2.000
VM
50-100
VM
10-20 VM 3-5
VM
open source Tools - •Soke •Soke •JMeter
•Grinder
•Gatling
•Apache
Bench
•Siege
kommerzielle Tools - •XLT •LoadRunner
•SilkPerformer

35. © iteratec
35
Auswahl der passenden Tools
HW-Bedarf
Tool-Kategorie echte
User
echte
Browser
simulierte
Browser
HTTP-Traffic einfache
HTTP-
Lastsynthetisch capture /
replay
Realitätstreue max sehr
hoch
hoch mittel max gering
Pflegeaufwand min gering gering hoch mittel mittel
HW-Bedarf (für
Ziellast)
2-5.000
PC
1-2.000
VM
50-100
VM
10-20 VM 3-5
VM
open source Tools - •Soke •Soke •JMeter
•Grinder
•Gatling
•Apache
Bench
•Siege
kommerzielle Tools -
•XLT •LoadRunner
•SilkPerformer

36. © iteratec
36
Agenda
 Erschlagen vom eigenen Erfolg
 Fahrplan zu entspannten Live-Gängen
 Definition von Lastanforderungen
 Lasttests zur Überprüfung der Lastanforderungen
 Auswahl der passenden Tools
 Auswertung von Lasttests
 Sizing der Systeme auf Basis von Lasttestergebnissen
 Erfahrungen und Ergebnisse in der Praxis

37. © iteratec
37
Auswertung von Lasttests
Überblick über die Gesamtlandschaft
Prelive-cluster
50 Lastgeneratoren (8 core, 8GB RAM)
jenkins-lpt
xltmaster-dev xltmaster-qa-166 xltmaster-qa-85
LoadBalancer
PA-Proxy PA-Proxy
Auth
Order
P13N
Product
…
SAN
LPT
LoadBalancer
PA-Proxy PA-Proxy
Auth
Order
P13N
Product
…
SAN Live
LoadBalancer
PA-Proxy PA-Proxy
Auth
Order
P13N
Product
…
SAN
Graphite Splunk
LoggingKPI

38. © iteratec
38
Auswertung von Lasttests
Auswertungen
Prelive-cluster
50 Lastgeneratoren (8 core, 8GB RAM)
jenkins-lpt
xltmaster-dev xltmaster-qa-166 xltmaster-qa-85
LoadBalancer
PA-Proxy PA-Proxy
Auth
Order
P13N
Product
…
SAN
LPT
LoadBalancer
PA-Proxy PA-Proxy
Auth
Order
P13N
Product
…
SAN Live
LoadBalancer
PA-Proxy PA-Proxy
Auth
Order
P13N
Product
…
SAN
Graphite Splunk
LoggingKPI
1.XLT-Report
2.Splunk-Report3.Graphite-Graph
1.Antwortzeiten
2.(Profiling) Log
3.Ressourcen-
Monitoring

39. © iteratec
39
 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 Lasttests
1 XLT-Report

40. © iteratec
40
 Verlängerung der Laufzeiten lässt Anzahl simulierter User
überproportional steigen
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder

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

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

43. © iteratec
43
 zunehmende Anzahl Timeouts lässt durchschnittliche Laufzeit
kontinuierlich steigen
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder

44. © iteratec
44
Live Demo
Auswertung von Lasttests
1. XLT-Report

45. © iteratec
45
 Ziel: Fehlerbild in der Anwendung ermitteln
 Whitebox-Sicht
 Basis: Performance-Logs der Anwendung
 Log-Dateien aller beteiligten Maschinen werden durch Splunk
eingesammelt und zentral indexiert und bereitgestellt
 Konsolidierung über Maschinengrenzen hinweg
 Konsolidierung über LogFile-Typen hinweg
 Dynamische AdHoc Queries möglich
 Explorative Untersuchung der Performance-Kennzahlen
 Detaillierung bis hin zum einzelnen Request
 Herausforderung:
 Zielsystem besteht aus einem Dutzend separaten Teilsystemen
 Welches Teilsystem ist für Performanceprobleme verantwortlich ?
Auswertung von Lasttests
2 Splunk-Report

46. © iteratec
46
RESTful Architektur1
Shared Nothing als
Architekturprinzip
2
Vertikaler
Systemschnitt
3
Zentrale Verantwort-
lichkeit für Daten
4
Buy when non coreA
Gemeinsame
Basistechnologien
B
Macro-Architektur
Micro-Architektur
Shopoffice
Shoppages
Search&Navigation
Product
Personalisation
Order
User
Tracking
Auth
AfterSales
ELCH
Frontend-Integration
Daten-Integration
Vertikale Systemarchitektur des Zielsystems
Funktionale Gliederung

47. © iteratec
47
Shopoffice
Shoppages
Search&Navigation(SAN)
Product
Personalisation
(P13N)
Order
User
Tracking
Auth
AfterSales
ELCH
Frontend-Integration
Daten-Integration
Vertikale Systemarchitektur des Zielsystems
Seitenkomposition
 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

48. © iteratec
48
 Dashboard
 Client  Backend Request Laufzeiten
 Aufteilung nach PageTag
 Welches System ist für Laufzeitprobleme verantwortlich ?
Auswertung von Lasttests
2 Splunk-Report

49. © iteratec
49
Live-Demo
Auswertung von Lasttests
2 Splunk-Report

50. © iteratec
50
 Rubriken für Ressourcenauslastung
 Physikalische Systemressourcen
 CPU
 Platten-IO
 RAM
 Netzwerk-IO
 Logische SW-Ressourcen
 Plattform (Tomcat Threadpool, Java GC)
 Anwendung (Pools, Queues, Synchronisation nebenläufiger Threads)
 Verlinkung Jenkins-Job  Graphoo Dashboards
 Details zur Ressourcenauslastung aller Maschinen
 Übersichts-Dashboard zu Performance- und Lasttests
 Graphoo = eigene Rails-Anwendung
 dynamische Generierung der Dashboards mit Graphite-Grafiken
 Basis : aktuelles Inventory der Umgebung + Dashboard-Config
Auswertung von Lasttests
3. Graphite-Graphen

51. © iteratec
51
 Graphoo Dashboard mit Graphite-Grafiken
Auswertung von Lasttests
3. Graphite-Graphen

52. © iteratec
52
Live-Demo
Auswertung von Lasttests
3. Graphite-Graphen

53. © iteratec
53
Agenda
 Erschlagen vom eigenen Erfolg
 Fahrplan zu entspannten Live-Gängen
 Definition von Lastanforderungen
 Lasttests zur Überprüfung der Lastanforderungen
 Auswahl der passenden Tools
 Auswertung von Lasttests
 Sizing der Systeme auf Basis von Lasttestergebnissen
 Erfahrungen und Ergebnisse in der Praxis

54. © iteratec
54
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 Lasttestergebnissen
Vorgehen
)(
)(
)(
)(
Re
Re
**)()( ReRe live
Test
Test
live
radslastungsgssourcenau
radslastungsgssourcenau
Last
Ziellast
ngTestumgebulive ssourcendarfssourcenbe 

55. © iteratec
55
 Vorgabe Ressourcenauslastung bei Ziellast
 Lineare Skalierbarkeit auf einer Maschine nur bis max. 50-70%
Ressourcenauslastung erreichbar
 Ausfallsicherheitsreserve 50%
 Ziel-Wert: 50% * 60% = 30%
 Vorgaben zum Server-/VM-Zuschnitt
 Ausfallsicherheit:
 AppServer: mindestens zwei Server pro Aufgabe
 MongoDB Replica-Set: mindestens 3 DBs im Replica-Verbund
 Ressourcen pro Server
 mindestens 2 core pro Server/VM (System + Applikation)
 nie swapping zulassen  ausreichend memory
 minimale disk size für sicheren Betrieb (logging, backup/restore)
Sizing der Systeme auf Basis von Lasttestergebnissen
Grundannahmen

56. © iteratec
56
Agenda
 Erschlagen vom eigenen Erfolg
 Fahrplan zu entspannten Live-Gängen
 Erfahrungen und Ergebnisse in der Praxis

57. © iteratec
57
 Kontinuierliche Lasttests seit 12 Monaten
 6 Ziel-Umgebungen, davon 3 für Lasttests genutzt
 Je Umgebung zwischen 50 und 150 VM
 50 VM‘s als Lastgeneratoren
 5-10 Lasttestläufe pro Tag
 5-10 GByte Ergebnisdaten pro Lasttestlauf
 ca. 100 Metriken pro VM pro Minute
 ca. 100 GByte tägliches Log-Volumen aus Lasttests
 3 große Meilensteine erfolgreich bewältigt
 Mitarbeitershop
 Closed Alpha
 Live Beta
Erfahrungen und Ergebnisse in der Praxis
Zahlen

58. © iteratec
58
 Ohne smarte Ziele geht es nicht.
 S = Spezifisch
 M = Messbar
 A = Akzeptiert
 R = Realistisch
 T = Terminiert
Erfahrungen und Ergebnisse in der Praxis
Lessons learned

59. © iteratec
59
 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 Praxis
Lessons learned

60. © iteratec
60
 Arbeitsstand für alle sichtbar visualisieren: Dashboard
Erfahrungen und Ergebnisse in der Praxis
Dashboard

61. © iteratec
61
 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 Praxis
Lessons learned

62. © iteratec
62
erreichterDurchsatz
Projektlaufzeit
Erfahrungen und Ergebnisse in der Praxis
Beispiele für aufgedeckte Skalierbarkeitsprobleme
Problem: Default-Konfiguration des nginx
beschränkt CPU-Nutzung auf einen Core
Lösung: Anpassung nginx-Konfiguration

63. © iteratec
63
erreichterDurchsatz
Projektlaufzeit
Erfahrungen und Ergebnisse in der Praxis
Beispiele für aufgedeckte Skalierbarkeitsprobleme
Problem: Auslieferung statischer
Ressourcen setzt App-Server unter Last
Lösung: Einführung Asset-Server für
statischen Content

64. © iteratec
64
erreichterDurchsatz
Projektlaufzeit
Erfahrungen und Ergebnisse in der Praxis
Beispiele für aufgedeckte Skalierbarkeitsprobleme
Problem: zu wenig RAM führt unter Last
zum Swapping der Such-Server
Lösung: mehr RAM

65. © iteratec
67
 Ziele müssen allgemein akzeptiert werden
 SMART
 Zielerreichung laufend kommunizieren
 Dashboard
 Probleme meist nicht dort, wo man sie vermutet
 Wirklichkeitsnähe
Entspannte Live-Gänge in Sachen Performance- und Lastverhalten
sind keine Utopie
Erfahrungen und Ergebnisse in der Praxis
Konsequenzen für die Gestaltung der Lasttests

66. © iteratec
68
Eure Fragen ?
Kontakt: Uwe.Bessle@iteratec.de
Iteratec GmbH