Einführung in Performance-Analyse und Profiling mit PHP

1. PERFORMANC E!?
Einführung in
Analyse und Optimierung auf
PHP & Mysql basierten Webanwendungen

2. Fe lix Pe te rs
●
Baujahr 1988
●
Bachelor Studium
●
Hochschule Esslingen
●
Hochschule Reutlingen
●
Freelancer – wichteldesign.de
●
Entwickler bei autonetzer.de
18.02.13 Performance!? 2

3. Das kommt jetzt
●
Was ist Performance
●
Analyse
●
Methoden / Tools
●
Metriken
●
Vorgehensweise
●
Praxis / Troubleshooting
18.02.13 Performance!? 3

4. Das kommt nicht
●
Load-Balancing
●
Datenbank Replikation
●
Webserver
●
Linux
18.02.13 Performance!? 4

5. Performance
Der Begriff Performance beschreibt:
die Güte einer Anwendung ergibt sich aus den
Erwartungen an diese in Bezug auf:
●
die benötigten Ressourcen
●
und Zeit
unter gegebenen Bedingungen.
18.02.13 Performance!? 5

6. Performance
●
Ressourcen sind nicht unendlich und kosten Geld
●
Unperformante Anwendungen kosten Geld
●
Zeit ergibt sich aus der Geschwindigkeit in der die
Anwendung Aufgaben erfüllen kann.
●
Ist vom Nutzer direkt spürbar
●
Hat direkten Einfluss auf das Nutzererlebnis
18.02.13 Performance!? 6

7. Qualität durch Performance
●
Nutzer sind durch Facebook & Co verwöhnt
●
Vergleichen damit die Anwendungen
=> Bessere Usability durch schnellere Anwendung
●
Rankingfaktor für Google
●
Bessere Position führt zu mehr Besuchern
18.02.13 Performance!? 7

8. Ausgangslage
Die Seite ist voll langsam!
http://techbeat.com/wp-content/uploads/2012/10/angrycomputerguy.gif
18.02.13 Performance!? 8

9. Keep Cool!
18.02.13 Performance!? 9

10. Kritische Use-Cases finden
●
Die Anwendung aufsplitten und getrennt betrachten!
●
Suchanfrage
●
Verarbeitung von Formulardaten
●
Checkout-Prozess
●
Uploads
●
Datenmanipulation
18.02.13 Performance!? 10

11. Akzeptanzkriterien
●
Wodurch entsteht das Gefühl langsam?
●
Was erwartet der Nutzer
●
Wie wird dem Nutzer Feedback gegeben?
●
Immer abhängig vom Use-Case!
18.02.13 Performance!? 11

12. Akzeptanzkriterien
formulieren
●
Ich will, dass die Aufgabe x bei einen gegebenen
Datenmenge y in der Zeit z erledigt ist.
●
Im Beispiel: Eine Suche nach Fahrzeugen in
Berlin (162 Stk.) soll unterhalb einer Sekunde
Ergebnisse anzeigen.
18.02.13 Performance!? 12

13. Der Mythos Performance
●
„Mit einem besseren Server wäre das alle kein
Problem“
●
„echo ist viel schneller als print“
●
„Mit vielen Joins kann das ja nix werden auf der
Datenbank“
Google Suche „performance tips php“ → Ungefähr 166.000.000 Ergebnisse (0,31 Sekunden)
18.02.13 Performance!? 13

14. Nicht raten → Messen!
Problem → messen → analysieren (→ optimieren)
18.02.13 Performance!? 14

15. Vorge he ns we is e
●
Einzelnen Use-Case von außen nach innen
●
Vom Groben ins feine
●
Ursachen einkreisen
18.02.13 Performance!? 15

16. De r Blic k aufs Ganze
●
Wie schnell reagiert die Anwendung?
●
Wie viel kann die Anwendung verarbeiten?
●
Wie verhält sich die Anwendung unter
verschiedener Last?
●
Tools: Apache Bench, Siege, Jmeter uvm.
18.02.13 Performance!? 16

17. De r Blic k aufs Ganze
18.02.13 Performance!? 17

18. Re s pons e Time
●
Die Zeit zwischen dem absetzten eines Request bis
zum eintreffen der Response des Servers
●
Beinhaltet den Download (gesamten Response)
aber nicht und Rendern / lokales Verarbeiten der
Response bzw. dessen Inhalt!
18.02.13 Performance!? 18

19. Throughput
●
Ergibt sich aus einer Vielzahl von Messungen
●
Definiert die Anzahl von:
Verarbeiteten Anfragen / Zeiteinheit
●
Bsp: 10 Anfragen / Sekunde
●
Steht im Verhältnis zur Response Time
18.02.13 Performance!? 19

20. Re s pons e Time vs .
Troughput
●
Der Troughput zeigt die Last die Server
verarbeiten muss
●
Die Response Time zeigt wie schnell er das
macht.
18.02.13 Performance!? 20

21. Bac ke nd – PHP Profiling
●
Kompleten Programmablauf aufzeichnen
●
Zeiten messen, CPU Auslastung, RAM Belegung
●
Tools:
●
Xdebug
● XHProf
●
(Framework) Eigene Zeitmessungen
18.02.13 Performance!? 21

22. PHP Profiling - Messwerte
●
Walltime, CPU-Time, Memory Usage, Call Count,
Call-Graph
18.02.13 Performance!? 22

23. Daten erhalten
●
Datenbanken (und Webservice-Aufrufe)
18.02.13 Performance!? 23

24. Datenbank - Messwerte
●
Zeit um Verbindung aufzubauen
●
Meistens zu vernachlässigen
●
Zeit um einen Query auszuführen
●
Verbrauchter RAM
●
Tools: Mysql (Explain, Log, usw.), (Framework /
ORM) eigene Messungen
18.02.13 Performance!? 24

25. Webservice - Messwerte
●
Zeit um Verbindung aufzubauen
●
Zeit um Daten zu empfangen
●
Meistens nicht zu beeinflussen
●
Wenn eigener Webservice → Gehe zurück auf Los
18.02.13 Performance!? 25

26. Fast geschafft!
Vorbereitungen zum testen
18.02.13 Performance!? 26

27. Test-Client und Sandbox
18.02.13 Performance!? 27

28. Sandbox nutzen
●
Aussagekräftige Test können nur unter immer
gleichen Bedingungen gemacht werden!
●
Das Host-System sauber halten
●
Virtuelles Netzwerk simulierbar
●
Tools: Virtual Box, VmWare, VAGRANT
18.02.13 Performance!? 28

29. Tests und Last erzeugen
●
Test automatisieren!
●
Immer mit selben Daten testen
●
Auch hier: Je nach Kontext testen!
●
Lasttest, Stresstest, Single Run
●
Tools: Jmeter erlaubt auch komplexe Tests
18.02.13 Performance!? 29

30. Ein paar Worte zum
Testdesign
●
Falsches Testdesign führt zu falschen Aussagen
●
Bsp: Die maximale Lastgrenze einer Anwendung
kann nur durch detaillierte Simulation von Nutzern
annähernd korrekt gemessen werden.
18.02.13 Performance!? 30

31. Bas e line e rs te lle n
●
Dient als Ausgangslage
●
Bei Frameworks, das Framework messen
18.02.13 Performance!? 31

32. Die fe rtige Umge bung
18.02.13 Performance!? 32

33. Ge nug The orie !
Wir werden dann mal praktisch
18.02.13 Performance!? 33

34. Und je tzt? Optimie re n? !
http://www.theillustratedprofessor.com/wp-content/uploads/2012/02/It-Depends-1.jpg
18.02.13 Performance!? 34

35. Es gibt ke in HowTo
●
Jedes Ergebnis muss einzeln im Kontext
betrachtet werden
●
Optimierungen müssen zusammenspielen
●
Alle gemachten Optimierungen testen
●
Im Einzelnen und und im Zusammenspiel
18.02.13 Performance!? 35

36. Je besser man das Problem versteht, umso
besser kann man es beheben!
18.02.13 Performance!? 36

37. Abe r e in paar Re ge ln
●
So geht es nicht:
●
Teure Funktionen in einer Schleife
●
Daten doppelt erzeugen
●
Statische Daten bei jedem Aufruf erzeugen
●
Nicht verwendete Daten erzeugen
●
Uvm.
18.02.13 Performance!? 37

38. Ein paar Regeln
●
So geht’s:
●
Die Response so früh wie möglich erzeugen
●
Nur benötigte Daten holen
●
Nicht zeitkritische Aufgaben verschieben
●
Statische Daten nur einmal vom Webservice holen
(Geocoding z.B)
●
Caching!
18.02.13 Performance!? 38

39. Datenbanken verstehen
●
Storage-Engines entsprechend anwenden
●
Querys analysieren und verstehen
●
Query-Cache nutzen
●
NOW() umgeht den Query-Cache
●
Ggf. Daten denormalisieren
●
Birgt aber gefahren
18.02.13 Performance!? 39

40. Fragen?
Follow Me:
@el_wichtel / @wichteldesign
Autonetzer?
Gutscheincode: iknowfelix
18.02.13 Performance!? 40