Niemand steht gerne in der Schlange an der Kasse im Supermarkt. Wenn es hier nicht voran geht, wechselt man einfach in den nächsten Laden ums Eck. Gut zu sehen: Eine Conversion-Optimierung allein bringt es noch nicht, auch Optimierungen unter der Haube wirken sich spürbar auf den Umsatz aus. Ganz gleich übrigens, ob Supermarkt oder E-Commerce-Software.
Benjamin Eberlei arbeitet bei Qafoo mit Tideways an einer Lösung für das Profiling von PHP-Applikationen, Björn Schotte berät für Mayflower E-Commerce-Spezialisten für den technischen Einsatz großer Shopsysteme. Beide Seiten ergänzen sich im Grunde prima für eine Performance-Optimierung — wir haben die zwei eingeladen, ihre Erfahrungen in einem passenden Webinar zusammenzustellen und den beiden einleitend ein paar Fragen gestellt.
Vielleicht vorab — für wen ist so eine Performance-Optimierung von E-Commerce-Systemen eigentlich interessant?
Björn: Als wir unsere Daten für das Webinar aufbereitet haben, standen ganz klar Entwickler im Fokus. Dennoch kann ich das Thema auch technisch orientierten Teamleitern und E-Commerce-Managern, bzw. Leitern E-Commerce ans Herz legen. Hier geht es um das grundlegende Verständnis, wie eine PHP-basierte Anwendung — also zum Beispiel ein Shop-System — auf Performance-Probleme hin untersucht werden kann.
Warum sollte ich meinen PHP-Shop profilen und welchen Nutzen ziehe ich daraus?
Björn: Es ist ein weit verbreitetes Missverständnis, dass nur die Conversion-Optimierung über die Oberfläche — also Produkt-Darstellung, vernünftige Call-to-Actions und so weiter — den Optimierungserfolg in einem Shopsystem beeinflusst. Tatsächlich liegt ein großes Potenzial darin, auch “unter der Haube” zu optimieren; nämlich direkt in der Software. Studien haben gezeigt, dass ein großer Hebel darin liegt, die Auslieferungszeiten einer einzelnen Seite zu minimieren. Natürlich spielen hier Optimierungen im Frontend (JavaScript, CSS) eine große Rolle. Dennoch dürfen Betreiber nicht die Optimierung im Backend vergessen. Wir kennen viele Beispiele, in denen ein einziger Seitenaufruf bereits einige tausend Abfragen an die Datenbank stellt — immer und immer wieder.
Benjamin: Ein Profiler unterstützt den Nutzer dabei, diese Performance-Probleme einzugrenzen und zu identifizieren, beispielsweise tausende solcher Datenbankaufrufe sichtbar zu machen. Das Ziel eines Profilings ist es, verlässliche Zahlen zu liefern, so dass man bei der Optimierung von langsamen Seiten nicht im Dunkeln stochert.
Wichtig ist auch, dass ich das Profiling sowohl auf den Entwicklermaschinen als auch in Produktion durchführen kann. Üblicherweise verhalten sich diese Systeme völlig unterschiedlich, da Last und Datenmenge in Produktion ganz anders ausfallen, als auf den Entwicklermaschinen.
Auch die zeitliche Komponente sollte man nicht außer Acht lassen: Über Tage, Wochen und Monate hinweg kann sich die Performance einzelner Seiten schleichend oder drastisch verändern. Es ist hilfreich, die Gründe für Veränderungen in der Performance schnell zu identifizieren.
Was für ein Aufwand ist damit verbunden, einen Profiler in einen Shop zu integrieren und welche Folgen hat das auf mein bestehendes Shopsystem?
Benjamin: Das hängt stark vom verwendeten Profiler ab. Die Installation selber ist bei den meisten Lösungen noch einfach. Bei den verschiedenen Open-Source-Profilern wie XHProf und Xdebug muss man sich zusätzlich um das Wie und Wo der Datenspeicherung und Anzeige kümmern, das entfällt bei Bezahldiensten wie Tideways, NewRelic oder Blackfire.
Zur Verwendung selbst ist es wichtig zu wissen: manche Profiler sind nur für die Nutzung auf Entwicklungsrechnern ausgelegt, da sie den Produktivbetrieb stark verlangsamen, dafür aber vielleicht mehr Informationen sammeln. Für Live-Betrieb geeignete Profiler sammeln weniger Informationen und können manchmal nur andeuten wo das Problem liegt.
Auswirkungen auf den Live-Betrieb haben Profiling und Monitoring jedoch immer, je nach Tool liegt der Overhead zwischen <10 Prozent und 200 Prozent.
Björn: Benjamin sagt es ganz richtig: es kommt darauf an. Jeder Optimierungsversuch sollte so konkret wie möglich angegangen werden. Gerade wenn Sie sich in einer gewachsenen Software befinden — und viele Online-Shops mit Millionenumsätzen sind gewachsene Systeme über die letzten acht, zehn Jahre — ist es wichtig herauszufinden, welchen Weg eine Abfrage vom Nutzer im Browser durch das System geht. Ein Profiler, der hier etwas tiefer mitloggt und ins System schaut, kann wertvolle Erkenntnisse liefern. Es dürfte sich allerdings von selbst verstehen, dass sie die maximale Logtiefe nicht unbedingt in ihren umsatzstärksten Stunden oder Minuten durchführen. ;-) Andererseits sollte ein Profiling auch nicht in komplett umsatzarmen Stunden durchgeführt werden, denn Sie benötigen ja auch eine entsprechende Menge an echten Nutzern, die dem Profiler den Weg zeigen.
Welche Metriken macht ein Profiling für mich als Shopbetreiber sichtbar?
Benjamin: Das sind zum Beispiel langsame Funktionen in der Software, oder Datenbankqueries. Ein Profiler liefert für eine ganz bestimmte Anfrage eines Nutzers oder Entwicklers sehr detaillierte Informationen, welcher Teil der Shopsoftware langsam ist. Diese Informationen kann man nicht bei jedem Seitenaufruf sammeln, das wäre viel zu teuer. Für den Shopbetreiber sind wir hier daher schon eine Ebene zu tief im Detail.
Spannend wird es, wenn ich das Profiling mit einer kontinuierlichen Überwachung des Live-Betriebs verknüpfe. Sieht man da bereits auf der Makroebene, das 95 Prozent aller Seitenbesucher bis zu 2 Sekunden auf das Laden der Checkout-Seite warten, die Artikel- und Kategorieseiten aber nur 400ms dauern, dann kann ich besser entscheiden, welche Module des Shops optimiert werden sollten. Noch interessanter ist es, die Veränderungen Woche für Woche zu beobachten.
Auch hier gilt, wie für das Profiling selber: Ohne verlässliche Zahlen zu den einzelnen Seitentypen aus dem Live-Betrieb kann ich eigentlich nur raten, wo Optimierungsbedarf besteht.
Björn: Ganz konkrete Engpässe, die sich in Ihrem System befinden, und die sich nur schwer, beispielsweise durch eine Test-Automation während der Entwicklung, herausfinden lassen. Wenn Sie so wollen, dann ist der Profiler der ideale Counterpart zu einem testgetriebenen Entwicklungsansatz. Natürlich ersetzt der Profiler beileibe keine TDD-Standards, dennoch ist er eine gute Ergänzung, um auch nach dem Produktiv-Deployment eine Optimierung vorzunehmen.
Was sind die typischen, technischen Probleme eines PHP-Shops?
Björn: In den letzten 15 Jahren sind mir eine ganze Reihe abenteuerlicher Dinge begegnet. Typische technische Probleme entstehen durch gewachsene Systeme und häufigem Feature-Druck durch das Business, während notwendige Modernisierungen auf die lange Bank geschoben werden. Mit anderen Worten, was wir bei Mayflower in unseren Beratungen immer wieder sehen: hausgemachte Probleme. Angefangen von extrem vielen Anfragen an die Datenbank, komische Softwarearchitekturen, nicht optimal konfigurierte Webserver, unnötig durchlaufener Programmcode, fehlende Test-Automatisierung und Continuous-Integration-Infrastruktur, nicht optimale Auslieferung von Frontend-Dateien (JavaScript, CSS, Media Assets), undurchsichtige Datenbankstrukturen und unmögliche Anbindungen an Dritt-Systeme, wie ERP- und PIM-Systeme.
Benjamin: Ob Shopsoftware von der Stange, oder selbstgeschrieben, Performance-Probleme sehen wir auch bei Qafoo in Kundenprojekten immer wieder. Shopsysteme ziehen aufgrund Ihrer Komplexität im Backend viele Datenbankabfragen nach sich und im Frontend viel Javascript, CSS und Bilder. Wichtig ist bei einem großen Berg von Performance Problemen eine gesunde Mischung aus kleinschrittigen Optimierungen der bestehenden Code-Basis und Architekturveränderungen für größere Sprünge zu fahren.
Benjamin Eberlei
Benjamin (@beberlei) arbeitet als Entwickler und Projektleiter bei der Qafoo GmbH an Tideways, einem PHP-Performance-Monitoring- und Profiling-Tool. Als Trainer und Berater für Softwarequalität ist er außerdem regelmäßig bei Kunden vor Ort und auf Konferenzen zu finden. In einem früheren Leben hat er das Open-Source-Projekt Doctrine 2 mitentwickelt und berät heute als einer der Projektleiter das Team bei der Weiterentwicklung.
Björn Schotte
Björn ist geschäftsführender Gesellschafter der Mayflower GmbH und Senior Consultant im Umfeld von Online- und Mobile-Lösungen. Er twittert unter @BjoernSchotte und ist auf Xing sowie in Google+ als Björn Schotte erreichbar.
Schreibe einen Kommentar