11.performance meetup lasttests

11. PerformanceMeetup

28. Mai 2013

Uwe.Bessle@iteratec.de

Effektiver Einsatz von Lasttests zur

Optimierung der Skalierbarkeit von

Web-Sites

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

Vom eigenen Erfolg erschlagen

Telekom Mobilfunkseite durch iPhone5 Andrang

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

DaWanda : zunehmende Ausfälle durch steigende Nutzerzahlen

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

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

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

Agenda

Beispiele aus der jüngeren Vergangenheit

Auch die Cloud ist kein Allheilmittel

Grundidee:

Einsatz von

Standardkomponenten zur

Lastverteilung (Load-Balancer)

+ horizontale Skalierbarkeit der

Anwendungskomponenten

+ dynamisches Buchen

zusätzlicher Ressourcen in der

= Lastprobleme einfach gelöst

Wozu brauche ich Lasttests, ich habe doch die Cloud ?

Internet

Firewall

LoadBalancer

Server

LoadBalancer

Server

Datenbank

(LDAP)

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

Server

LoadBalancer

Server

Datenbank

(LDAP)

Agenda

Definition von Lastanforderungen

Lasttests zur Überprüfung der Lastanforderungen

Auswahl der passenden Tools

Auswertung von Lasttests

Sizing der Systeme auf Basis von Lasttestergebnissen

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

Betrachtungs-Zeitraum,

statische Ressourcen,

AJAX-Requests,

Tracking-Requests,

API-Calls

Typische Kennzahlen

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

Betrachtungs-Zeitraum : Typische Tageskurve

Betrachtungs-Zeitraum : Monatsverlauf

relevante Kennzahl

für Businessplan

maßgebliches Ziel

für Lasttest

Statische Ressourcen

bis zu 100 Bilder, Javascript- und CSS-Dateien pro Seitenaufruf

Übersehene Anforderungsbestandteile : Statische Ressourcen

MIME Type Requests▼

image 80

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)

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

Abgestuftes Vorgehen mit mehreren Meilensteinen

Woher kommen konkrete Anforderungen ?

1. Ablösung Altsystem: Zahlen zur Nutzung des Altsystem

Web-Tracking (fachliche Kennzahlen) !

Monitoring (technische Kennzahlen)

Quellen für Anforderungen

Seitenverteilung aus dem Web-Tracking

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

Agenda

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

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

Typische Anforderung : Lineare Skalierbarkeit

Anzahl User

Messung mit linear steigender Last

Beispiel: Durchsatzmessung in Abhängigkeit von der Last

Lastkurve bei idealem

Systemverhalten

(lineare Skalierbarkeit)

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)

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

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

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

Einordnung der Lasttests in die Build- und Release-Pipeline

Perfor-mance Lasttest

Robust-heit

System-LPT

Robust-heit

Abnahme-LPT

Einordnung der Lasttests in die Build- und Release-Pipeline

Komponenten-LPT

Agenda

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

HW-Bedarf

Tool-Kategorie echte

Browser

simulierte

Browser

HTTP-Traffic einfache

Last synthetisch capture /

replay

Realitätstreue max sehr

hoch mittel max gering

Pflegeaufwand min gering gering hoch mittel mittel

HW-Bedarf (für

Ziellast)

2-5.000

1-2.000

50-100

10-20 VM 3-5

open source Tools - •Soke •Soke •JMeter

•Grinder

•Gatling

•Apache

•Siege

kommerzielle Tools - •XLT •LoadRunner

•SilkPerformer

HW-Bedarf

Tool-Kategorie echte

Browser

simulierte

Browser

HTTP-Traffic einfache

Last synthetisch capture /

replay

Realitätstreue max sehr

hoch mittel max gering

Pflegeaufwand min gering gering hoch mittel mittel

HW-Bedarf (für

Ziellast)

2-5.000

1-2.000

50-100

10-20 VM 3-5

open source Tools - •Soke •Soke •JMeter

•Grinder

•Gatling

•Apache

•Siege

kommerzielle Tools - •XLT •LoadRunner

•SilkPerformer

Agenda

Ü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

LoadBalancer

PA-Proxy PA-Proxy

LoadBalancer

PA-Proxy PA-Proxy

Graphite Splunk

Logging KPI

Auswertungen

Prelive-cluster

50 Lastgeneratoren (8 core, 8GB RAM)

jenkins-lpt

xltmaster-dev xltmaster-qa-166 xltmaster-qa-85

LoadBalancer

PA-Proxy PA-Proxy

LoadBalancer

PA-Proxy PA-Proxy

LoadBalancer

PA-Proxy PA-Proxy

Graphite Splunk

Logging KPI

1.XLT-Report

2.Splunk-Report 3.Graphite-Graph

1.Antwortzeiten

2.(Profiling) Log 3.Ressourcen-

Monitoring

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

Verlängerung der Laufzeiten lässt Anzahl simulierter User

überproportional steigen

1 XLT-Report : Typische Fehlerbilder

Stau auf der Datenautobahn

Erwartete Kurve

Einbruch nach Erreichen einer Lastgrenze = Überlast

zunehmende Anzahl Timeouts lässt durchschnittliche Laufzeit

kontinuierlich steigen

Live Demo

1. XLT-Report

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

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

office

Search

avigat

nalisa

Frontend-Integration

Daten-Integration

Vertikale Systemarchitektur des Zielsystems

Funktionale Gliederung

office

Search

avigat

ion (S

nalisa

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

Dashboard

Client Backend Request Laufzeiten

Aufteilung nach PageTag

Welches System ist für Laufzeitprobleme verantwortlich ?

2 Splunk-Report

Live-Demo

2 Splunk-Report

Rubriken für Ressourcenauslastung

Physikalische Systemressourcen

Platten-IO

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

Graphoo Dashboard mit Graphite-Grafiken

3. Graphite-Graphen

Live-Demo

3. Graphite-Graphen

Agenda

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**)()( ReRe

radslastungsgssourcenau

ZiellastngTestumgebulive ssourcendarfssourcenbe

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

Agenda

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

Ohne smarte Ziele geht es nicht.

S = Spezifisch

M = Messbar

A = Akzeptiert

R = Realistisch

T = Terminiert

Lessons learned

S = Spezifisch

M = Messbar

A = Akzeptiert

R = Realistisch

T = Terminiert

Zielerreichung laufend kommunizieren und visualisieren

Dashboard

Lessons learned

Arbeitsstand für alle sichtbar visualisieren: Dashboard

Dashboard

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

Projektlaufzeit

Beispiele für aufgedeckte Skalierbarkeitsprobleme

Problem: Default-Konfiguration des nginx

beschränkt CPU-Nutzung auf einen Core

Lösung: Anpassung nginx-Konfiguration

Projektlaufzeit

Problem: Auslieferung statischer

Ressourcen setzt App-Server unter Last

Lösung: Einführung Asset-Server für

statischen Content

Projektlaufzeit

Problem: zu wenig RAM führt unter Last

zum Swapping der Such-Server

Lösung: mehr RAM

Ziele müssen allgemein akzeptiert werden

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

Eure Fragen ?

Kontakt: Uwe.Bessle@iteratec.de

Iteratec GmbH

11.performance meetup lasttests

Technology

Transcript of 11.performance meetup lasttests

Synthetische Lasttests auf dem 100-Gigabit-Testbed ... · • Alcatel-Lucents 7750 Service Router: 0.08 ms (Messungen an einem Standort) 30

Über mich - Marc Niliusmit WP-CLI . WordPress Meetup Bonn WordPress-Site auf HTTPS umstellen • Resultat in den Developer Tools prüfen . WordPress Meetup Bonn WordPress-Site auf

Tipps und Tricks - solidworks.cad.desolidworks.cad.de/download/tt-catpro2005_performance.pdf · Tipps und Tricks Performance, Performance, Performance … aber woher nehmen? CAD.de

38. Open Data MeetUp & Talk Stadt Wien · Open Data Wien – Termine 2020/2021 Datum Event 26.03.2020 38. Open Data MeetUp & Talk Stadt Wien + 27.03.2020 Veröffentlichung Phase 38

Performance – Das Magazin von Performance Flooring. Ausgabe 1/2012

Ansible - ConSol Labs · Ansible Einführung und Hands-on Michael Kraus Meetup „Ansible im Monitoring-Umfeld“ / München, 27. Juli 2016

#03 TaxTech Meetup in Düsseldorf - Recht logisch · 2019-03-14 · #03 TaxTech Meetup in Düsseldorf STARTPLATZ - 12.03.2019 2 Allgemein Fachvortrag BPMN im Steuerrecht – Darstellung

Childthemes mit git – WordPress MeetUp CGN

PowerPoint-Präsentationid17.at/wp-content/uploads/2017/10/11_Erich_Schuster.pdf · Chatbot Meetup, Deep Learning Meetup BUCHPRÄSENTATIONEN Mario Herger "Der Letzte Führerscheinneuling

Kubernetes bei Chefkoch (Bonn Agile Meetup, 05/2016)

Performance Line Performance Line · Robert Bosch GmbH Bosch eBike Systems 72703 Reutlingen GERMANY 0 276 001 SPI (2015.06) T / 220 WEU Performance Line Performance Line TURBOSPORT

Designers ❤️ Developers – Designers & Developers Darmstadt Meetup, 24.11.2015

Daten für Performance-Testsdatabene.org/download/Daten fuer Performance Tests-Volker...Diese Schritte sind Bestandteil fast jeden Performance-Tests Performance Testing Process 3 1.

Zühlke Meetup - Mai 2017

Einführung JMeter. Agenda - über OGVIT - Warum Lasttests - Was ist JMeter - Wie arbeitet JMeter - Skripte für JMeter - Tests planen - Testen - Ergebnisse.

Meetup Session - V.E.R.S. Leipzig GmbH · 33% 67% Insgesamt: ca. 230.000 Versicherungsvermittler freie Versicherungsvermittler (i.d.R. Versicherungsmakler) gebundene Versicherungsvermittler

FROM CONTENT CONVERSIONfiles.meetup.com/17181022/Content-Marketing... · FROM CONTENT 2 CONVERSION Robin Pratap (ASANAYOGA.DE) Content Marketing Meetup 17.02.2015 • Traffic

VOLVO FH PERFORMANCE EDITION - Volvo · PDF fileVolvo fh performance EDITION DIE VOLVO FH PERFORMANCE EDITION ist die ideale Kombination von herausragender Performance, Stil und Treibstoffeffizienz

high PERFORMANCE 01|2012 PERFORMANCE - Walter Tools · high PERFORMANCE 01|2012 high PERFORMANCE 01|2012 8 9 unternehmen unternehmen Energie sind in den vergangenen Jahren enorm teuer

Lasttests von Webanwendungen und korrespondierende ... · Lasttests von Webanwendungen und korrespondierende Optimierungen Loadtestingofwebapplicationsand correspondingoptimizations