"Die Performance steigern wir dann später durch Caching?" @ code.talks 2014

Webseiten müssen schnell sein, denn die Bereitschaft, auf das Laden einer Webseite zu warten, sinkt stetig. Folglich zählt jede Millisekunde, wenn es darum geht, Absprünge zu vermeiden. Egal ob reale Ladezeiten, gefühlte Dauer des Seitenaufbaus oder das Reaktionsverhalten im Browser – es gibt viele Stellen, an denen im Client gemessen und regelmäßig optimiert wird. Tauchen Engpässe hingegen im Backend auf, gilt scheinbar vor allem eine Parole: exzessives Caching! Blöd nur, wenn sich Inhalte so häufig ändern, dass diese Maßnahme praktisch wirkungslos ist. Könnte man doch nur eine Applikation so entwerfen, dass sie ohne Caching hochperformant arbeitet…

Transcript

1. ARNE BLANKERTS SEBASTIAN HEUER “Die Performance steigern wir dann später durch Caching?” BASED ON A TRUE STORY PRESENTED IN FULL HD BY THEPHP.CC AND GLOBETROTTER AUSRUESTUNG BASED ON THE EXPERIENCE OF ARNE BLANKERTS, STEFAN PRIEBSCH, SEBASTIAN BERGMANN AND SEBASTIAN HEUER PERFORMANCE DA TA TAKEN FROM GLOBETROTTER.DE GRAPHS PROVIDED BY METAWAYS INFOSYSTEMS PREMIERING AT CODE.TALKS 2014 IN HAMBURG
2. ARNE BLANKERTS THEPHP.CC http://thephp.cc
3. SEBASTIAN HEUER GLOBETROTTER AUSRÜSTUNG http://sebastianheuer.de
4. ERSTER AKT
6. SHOP DB BROWSER SYSTEMARCHITEKTUR ERP PIM
7. SHOP DB ABFRAGE DER ARTIKELDATEN Komplexe Queries, da normalisierte Datenhaltung. Furchtbar teuer. Wird immer on Request gemacht. SUCHE MIT FILTERN Dynamisch generierte Query mit diversen Bedingungen für die Filter. Aus Entwicklersicht fehleranfällig. Teuer, schlecht cachebar (Query Cache)
9. FILTER-QUERIES
11. SHOP DB BROWSER SEARCH FILTERN ÜBER SUCHMASCHINE ERP PIM
15. IDEE: SEITEN CACHEN
16. ANTWORTEN CACHEN SHOP DB BROWSER SEARCH CACHE ERP PIM
17. PROBLEM: ZU VIELE MÖGLICHE FILTERKONFIGURATIONEN FÜR SINNVOLLES CACHING
20. << REWIND
21. ZWEITER AKT
22. NEUER ANSATZ
23. WIE WIRD DIE SEITE SCHNELL? KURZE ANTWORTZEITEN
24. ARBEIT VERMEIDEN WIE WERDEN DIE ANTWORTZEITEN KURZ?
26. ERKENNTNIS: ECHTE ARBEIT MUSS WOANDERS PASSIEREN
27. UND WAS IST MIT DEM REST? WELCHE ARBEIT ERFOLGT IM REQUEST?
28. WAS BRAUCHEN WIR EIGENTLICH FÜR DIE BEANTWORTUNG EINES REQUESTS? • ARTIKELSTAMMDATEN • ARTIKELBEWERTUNGEN • BESTÄNDE • PREISE
30. WAS BRAUCHEN WIR WIRKLICH FÜR DIE BEANTWORTUNG EINES REQUESTS? • HTML-AUSGABE
31. • ARTIKELSTAMMDATEN • ARTIKELBEWERTUNGEN • BESTÄNDE • PREISE • HTML-AUSGABE !=
32. WER ERZEUGT DIE HTML-AUSGABE?
33. WILLKOMMEN BEIM REST
34. WENN SICH ARTIKELDATEN ÄNDERN WANN ERZEUGEN WIR DIE HTML-AUSGABE?
35. WANN ÄNDERN SICH ARTIKELDATEN? • NEUE PREISE / BESTÄNDE AUS DEM ERP • REDAKTEUR LÄDT NEUES ARTIKELBILD HOCH • SHOPMANAGER GIBT NEUE ARTIKELBEWERTUNG FREI
36. WIE ERZEUGEN WIR DIE HTML-AUSGABE?
37. Snippet list_item_100561 Snippet Snippet Snippet list_item_103541 Snippet Snippet Snippet list_item_108112 Snippet Snippet Snippet list_item_204936 Snippet Snippet Snippet Snippet Snippet Snippet
38. WAS HEIßT DAS FÜR UNSERE SYSTEMARCHITEKTUR?
39. ALTE, ZENTRALISTISCHE ARCHITEKTUR SHOP DB ERP PIM BROWSER SEARCH
40. NEUE ARTIKELDATEN KEY/VALUE STORAGE SEARCH BACKEND ERP PIM
41. EINGEHENDER REQUEST FRONTEND KEY/VALUE STORAGE SEARCH BROWSER BACKEND ERP PIM
42. FRONTEND KEY/VALUE STORAGE SEARCH BACKEND NEUE, VERTEILTE ARCHITEKTUR BROWSER ERP PIM
43. ZAHLEN AUS DER PRAXIS
44. • DURCHSCHNITTLICH: 32 PI/S (4 X 8 PI/S) • PEAK: 140 PI/S (4 X 35 PI/S) • KEINE AUSWIRKUNG AUF DIE LADEZEITEN • MAX. 5 AKTIVE PROZESSE JE MASCHINE
47. ERGEBNIS: DIE SEITE IST OHNE CACHES SCHNELL
48. HAPPY END!
49. @GLOBETROTTERDEV @BELANUR @THEPHPCC @ARNEBLANKERTS