Der Titel dieses Beitrages stammt von Marissa Meyer (heute CEO von Yahoo).
Jeder von Ihnen weiß wie ernst wir das Thema schneller Seitenaufbau des Shops behandeln.
Ohne Selbstlob zu verbreiten, können wir seit je her selbstbewusst behaupten zu den schnellsten Shopsystemen am Markt zu gehören. In unserem Segment gar das schnellste? Egal, ausruhen ist nicht. Ich mag hier intern sicher dem ein oder anderen Entwickler mit meiner pingeligen Art zu dem Thema auf den Wecker gehen, kann aber die Auswirkungen stets mit Argumenten untermauern und halte es weiterhin für einen in vielerlei Hinsicht enorm wichtigen Part unserer gemeinsamen Weiterentwicklung.
Um hier nicht einzuschlafen haben wir im Hintergrund (das merken Sie nicht) in den letzten Wochen wieder Neuerungen in Richtung Performanceverbesserungen im System vorgenommen.
Da wären zum einem neue Messmethoden unserer Skripte um noch schneller auf die langsamen Programmteile aufmerksam gemacht zu werden. Das hat uns hier ein großes Stück weiter gebracht.
Da wäre zum anderen ein neuartiges dynamisches Verhalten des Systems bei hohem Besucherandrang, mit anderen Worten: Bestimmte Dinge lassen wir bei zu hoher Serverbelastung anders verarbeiten. Ihr System merkt das automatisch, da die Serverlast als Kennwert stets verfügbar ist. Beispielsweise sind RAND() Befehle bei MySQL Selects sehr belastend für das System. Also wenn Ergebnisse per Zufall sortiert werden sollen. Damit tut sich jede SQL Datenbank auch heute noch schwer. Steigt die Serverlast über einen bestimmten Prozentsatz, lassen wir z.B. per Zufall sortierte "Kunden die das gekaufte haben, kauften auch..." - Artikel nach einer jede Nacht neu generierten Zufallszahl sortieren. Schützen damit das System vor zu großer Last und sorgen für kurzzeitig schnelleren Seitenaufbau, bis der Performance-Peek vorbei ist.
Schon länger haben wir uns mit unterschiedlichen (in der Regel) selbst entwickelten Caching-Methoden Beschäftigt. Sprich Code-Fragmente, die bei jedem Klick eines anderen Besuchers normalerweise mühsam aus der Datenbank geholt werden, in fest abgespeicherte Dateien zu packen, um bei Bedarf bereits fertig generiert geladen zu werden. Die Auffrischung dieser Code-Fragmente erfolgt dann immer entweder nachts oder wenn Sie z.B. den betroffenen Artikel oder die entsprechende Maske (kann auch ein Banner sein) im Backend speichern. Das alles merken Sie als Nutzer nicht. Es ist aber ein Teil des Geheimnisses warum POWERGAP so verdamm schnell lädt.
In den letzten Wochen haben wir das Thema Caching als Vorbereitung auf das nächste Weihnachtsgeschäft nochmals optimiert. Wir sind selbst bei sehr kleinen Teilen des Systems zu diesen Methoden übergegangen. Also um auch 2 oder 3 SQL Befehle einzusparen. Zuvor messen wir natürlich in Last-Simulationen, ob sich diese Optimierung auch lohnt! Damit schaffen wir einerseits immer einen gesunden Vorsprung in Sachen Geschwindigkeit zu unseren Mitbewerbern, zum anderen schaffen wir Luft um wieder neue Features die dann ja in der Regel auch neue Performance in Anspruch nehmen anbieten zu können. z.B. auf die neue POWERsuche, die nach einem halben Jahr Entwicklung bald vorgestellt wird
Jeder von Ihnen weiß wie ernst wir das Thema schneller Seitenaufbau des Shops behandeln.
Ohne Selbstlob zu verbreiten, können wir seit je her selbstbewusst behaupten zu den schnellsten Shopsystemen am Markt zu gehören. In unserem Segment gar das schnellste? Egal, ausruhen ist nicht. Ich mag hier intern sicher dem ein oder anderen Entwickler mit meiner pingeligen Art zu dem Thema auf den Wecker gehen, kann aber die Auswirkungen stets mit Argumenten untermauern und halte es weiterhin für einen in vielerlei Hinsicht enorm wichtigen Part unserer gemeinsamen Weiterentwicklung.
Um hier nicht einzuschlafen haben wir im Hintergrund (das merken Sie nicht) in den letzten Wochen wieder Neuerungen in Richtung Performanceverbesserungen im System vorgenommen.
Da wären zum einem neue Messmethoden unserer Skripte um noch schneller auf die langsamen Programmteile aufmerksam gemacht zu werden. Das hat uns hier ein großes Stück weiter gebracht.
Da wäre zum anderen ein neuartiges dynamisches Verhalten des Systems bei hohem Besucherandrang, mit anderen Worten: Bestimmte Dinge lassen wir bei zu hoher Serverbelastung anders verarbeiten. Ihr System merkt das automatisch, da die Serverlast als Kennwert stets verfügbar ist. Beispielsweise sind RAND() Befehle bei MySQL Selects sehr belastend für das System. Also wenn Ergebnisse per Zufall sortiert werden sollen. Damit tut sich jede SQL Datenbank auch heute noch schwer. Steigt die Serverlast über einen bestimmten Prozentsatz, lassen wir z.B. per Zufall sortierte "Kunden die das gekaufte haben, kauften auch..." - Artikel nach einer jede Nacht neu generierten Zufallszahl sortieren. Schützen damit das System vor zu großer Last und sorgen für kurzzeitig schnelleren Seitenaufbau, bis der Performance-Peek vorbei ist.
Schon länger haben wir uns mit unterschiedlichen (in der Regel) selbst entwickelten Caching-Methoden Beschäftigt. Sprich Code-Fragmente, die bei jedem Klick eines anderen Besuchers normalerweise mühsam aus der Datenbank geholt werden, in fest abgespeicherte Dateien zu packen, um bei Bedarf bereits fertig generiert geladen zu werden. Die Auffrischung dieser Code-Fragmente erfolgt dann immer entweder nachts oder wenn Sie z.B. den betroffenen Artikel oder die entsprechende Maske (kann auch ein Banner sein) im Backend speichern. Das alles merken Sie als Nutzer nicht. Es ist aber ein Teil des Geheimnisses warum POWERGAP so verdamm schnell lädt.
In den letzten Wochen haben wir das Thema Caching als Vorbereitung auf das nächste Weihnachtsgeschäft nochmals optimiert. Wir sind selbst bei sehr kleinen Teilen des Systems zu diesen Methoden übergegangen. Also um auch 2 oder 3 SQL Befehle einzusparen. Zuvor messen wir natürlich in Last-Simulationen, ob sich diese Optimierung auch lohnt! Damit schaffen wir einerseits immer einen gesunden Vorsprung in Sachen Geschwindigkeit zu unseren Mitbewerbern, zum anderen schaffen wir Luft um wieder neue Features die dann ja in der Regel auch neue Performance in Anspruch nehmen anbieten zu können. z.B. auf die neue POWERsuche, die nach einem halben Jahr Entwicklung bald vorgestellt wird
