11.performance meetup lasttests

11. PerformanceMeetup

28. Mai 2013

[email protected]

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

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

















© iteratec

4


DaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen

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

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





© iteratec

5


GovData: www.daten-deutschland.de vom Start weg überlastet

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

http://www.daten-deutschland.de



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











© iteratec

6

Agenda


Beispiele aus der jüngeren Vergangenheit

Auch die Cloud ist kein Allheilmittel



© iteratec

7


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


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



Definition von Lastanforderungen

Lasttests zur Überprüfung der Lastanforderungen

Auswahl der passenden Tools

Auswertung von Lasttests

Sizing der Systeme auf Basis von Lasttestergebnissen


© 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


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


Woran ausrichten

© iteratec

12


Betrachtungs-Zeitraum : Typische Tageskurve

© iteratec

13


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


Ü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?

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)


Übersehene Anforderungsbestandteile : Bot-Requests

© iteratec

16


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)


Quellen für Anforderungen

© iteratec

18

Seitenverteilung aus dem Web-Tracking



© 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



© iteratec

20

Agenda









© 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


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


Begriffsklärung

© iteratec

23


Typische Anforderung : Lineare Skalierbarkeit

Anzahl User

© iteratec

24

Messung mit linear steigender Last


Beispiel: Durchsatzmessung in Abhängigkeit von der Last

© iteratec

25




Lastkurve bei idealem

Systemverhalten

(lineare Skalierbarkeit)

© iteratec

26


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,



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, ...)


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


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


Regelmäßige Lasttests

© iteratec

30


Einordnung der Lasttests in die Build- und Release-Pipeline

© iteratec

31

Perfor-mance Lasttest

Robust-heit

System-LPT


Robust-heit

Abnahme-LPT


Einordnung der Lasttests in die Build- und Release-Pipeline


Komponenten-LPT

© iteratec

32

Agenda









© 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


Tool-Klassen

© iteratec

34


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


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









© iteratec

37


Ü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


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)


1 XLT-Report

© iteratec

40

Verlängerung der Laufzeiten lässt Anzahl simulierter User

überproportional steigen


1 XLT-Report : Typische Fehlerbilder

© iteratec

41

Stau auf der Datenautobahn



Erwartete Kurve

© iteratec

42

Einbruch nach Erreichen einer Lastgrenze = Überlast



© iteratec

43

zunehmende Anzahl Timeouts lässt durchschnittliche Laufzeit

kontinuierlich steigen



© iteratec

44

Live Demo


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 ?


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 ?


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


3. Graphite-Graphen

© 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


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)


Grundannahmen

© 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


Zahlen

© iteratec

58

Ohne smarte Ziele geht es nicht.

S = Spezifisch

M = Messbar

A = Akzeptiert

R = Realistisch

T = Terminiert


Lessons learned

© iteratec

59


S = Spezifisch

M = Messbar

A = Akzeptiert

R = Realistisch

T = Terminiert

Zielerreichung laufend kommunizieren und visualisieren

Dashboard


Lessons learned

© iteratec

61


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


Lessons learned

© iteratec

62

err

eic

hte

r D

urc

hsatz

Projektlaufzeit


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



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



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


Konsequenzen für die Gestaltung der Lasttests

11.performance meetup lasttests

Technology

Transcript of 11.performance meetup lasttests