Upload
uwe-bessle
View
576
Download
1
Embed Size (px)
DESCRIPTION
Präsentation zum Thema Lasttests auf dem 11. Performance Meetup in Hamburg
Citation preview
11. PerformanceMeetup
28. Mai 2013
Effektiver Einsatz von Lasttests zur
Optimierung der Skalierbarkeit von
Web-Sites
© 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
© 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
© iteratec
4
Vom eigenen Erfolg erschlagen
DaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen
Quelle: http://de.dawanda.com/topic/2169/10130642
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© iteratec
12
Definition von Lastanforderungen
Betrachtungs-Zeitraum : Typische Tageskurve
© iteratec
13
Definition von Lastanforderungen
Betrachtungs-Zeitraum : Monatsverlauf
relevante Kennzahl
für Businessplan
maßgebliches Ziel
für Lasttest
© 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)
© iteratec
15
Woher kommen zusätzliche Requests?
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
© iteratec
16
Definition von Lastanforderungen
Abgestuftes Vorgehen mit mehreren Meilensteinen
© 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
© iteratec
18
Seitenverteilung aus dem Web-Tracking
Definition von Lastanforderungen
Quellen für Anforderungen
© 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
© 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
© 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
© 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
© iteratec
23
Lasttests zur Überprüfung der Lastanforderungen
Typische Anforderung : Lineare Skalierbarkeit
Anzahl User
© iteratec
24
Messung mit linear steigender Last
Lasttests zur Überprüfung der Lastanforderungen
Beispiel: Durchsatzmessung in Abhängigkeit von der Last
© 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)
© 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)
© 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
© 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
© 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
© iteratec
30
Lasttests zur Überprüfung der Lastanforderungen
Einordnung der Lasttests in die Build- und Release-Pipeline
© 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
© 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
© 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
© iteratec
34
Auswahl der passenden Tools
HW-Bedarf
Tool-Kategorie echte
User
echte
Browser
simulierte
Browser
HTTP-Traffic einfache
HTTP-
Last synthetisch 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
© iteratec
35
Auswahl der passenden Tools
HW-Bedarf
Tool-Kategorie echte
User
echte
Browser
simulierte
Browser
HTTP-Traffic einfache
HTTP-
Last synthetisch 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
© 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
© 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
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
Logging KPI
© 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
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
Logging KPI
1.XLT-Report
2.Splunk-Report 3.Graphite-Graph
1.Antwortzeiten
2.(Profiling) Log 3.Ressourcen-
Monitoring
© 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
© iteratec
40
Verlängerung der Laufzeiten lässt Anzahl simulierter User
überproportional steigen
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
© iteratec
41
Stau auf der Datenautobahn
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
Erwartete Kurve
© iteratec
42
Einbruch nach Erreichen einer Lastgrenze = Überlast
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
© iteratec
43
zunehmende Anzahl Timeouts lässt durchschnittliche Laufzeit
kontinuierlich steigen
Auswertung von Lasttests
1 XLT-Report : Typische Fehlerbilder
© iteratec
44
Live Demo
Auswertung von Lasttests
1. XLT-Report
© 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
© iteratec
46
RESTful Architektur 1
Shared Nothing als Architekturprinzip 2
Vertikaler Systemschnitt 3
Zentrale Verantwort-lichkeit für Daten 4
Buy when non core A
Gemeinsame Basistechnologien B
Macro-Architektur
Micro-Architektur
Shop
office
Shop
pages
Search
& N
avigat
ion
Produ
ct
Perso
nalisa
tion
Order
User
Track
ing
Auth
After
Sales
ELCH
Frontend-Integration
Daten-Integration
Vertikale Systemarchitektur des Zielsystems
Funktionale Gliederung
© iteratec
47
Shop
office
Shop
pages
Search
& N
avigat
ion (S
AN)
Produ
ct
Perso
nalisa
tion
(P13N
)
Order
User
Track
ing
Auth
After
Sales
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
© iteratec
48
Dashboard
Client Backend Request Laufzeiten
Aufteilung nach PageTag
Welches System ist für Laufzeitprobleme verantwortlich ?
Auswertung von Lasttests
2 Splunk-Report
© iteratec
49
Live-Demo
Auswertung von Lasttests
2 Splunk-Report
© 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
© iteratec
51
Graphoo Dashboard mit Graphite-Grafiken
Auswertung von Lasttests
3. Graphite-Graphen
© iteratec
52
Live-Demo
Auswertung von Lasttests
3. Graphite-Graphen
© 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
© 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
ZiellastngTestumgebulive ssourcendarfssourcenbe
© 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
© iteratec
56
Agenda
Erschlagen vom eigenen Erfolg
Fahrplan zu entspannten Live-Gängen
Erfahrungen und Ergebnisse in der Praxis
© 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
© 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
© 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
© iteratec
60
Arbeitsstand für alle sichtbar visualisieren: Dashboard
Erfahrungen und Ergebnisse in der Praxis
Dashboard
© 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
© iteratec
62
err
eic
hte
r D
urc
hsatz
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
© iteratec
63
err
eic
hte
r D
urc
hsatz
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
© iteratec
64
err
eic
hte
r D
urc
hsatz
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
© 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