Shopware Hosting Performance
Im September 2019 rief mich ein langjähriger Kunde an. Wir haben für Ihn schon den Magento Shop sowie zuletzt eine Eigenentwicklung seines Entwicklerteams gehostet. HHVM, PHP-FPM und auch Docker Container waren Techniken, die wir hierfür zur Verfügung gestellt haben.
Bei seinem Anruf teilte er mir jedoch mit, dass er mit seinem Shop auf Shopware umsteigt und die Agentur bereits kurz vor der Fertigstellung steht. Üblicherweise hat die Agentur ihm geraten, das Hosting auf einen empfohlenen Provider der Agentur umzustellen. Es handelte sich dabei um einen bekannten niedersächsischen Provider der sich mit NGinx Hosting auf Shopware spezialisiert hat. Der Kunde teilte mir mit, dass er diesem Umzug nur sehr ungern zugestimmt hat. Jedoch möchte er als Shopbetreiber sicherstellen, dass die Agentur mit dem Hoster gut zusammenarbeitet. Die Agentur meinte, dass es nur bei dem einen Hoster, den Sie empfehlen, möglich wäre.
Selbstverständlich haben wir das akzeptiert und soweit alles in die Wege geleitet.
Am Tag des Umzug des Shops auf das neue Serversystem sah soweit alles gut aus. Durch die Verwendung von Cloudflare konnte die Domain augenblicklich auf den neuen Server umgestellt werden.
Gegen Mittag klingelte erneut das Telefon. Es war der Kunde. Er war sehr erregt weil der neue Shop erhebliche Probleme bei der Erreichbarkeit zeigte. Er bat unsere Technik eine Analyse des Problems bei dem anderen Hoster zu erstellen da sowohl die Agentur als auch der Hoster unzureichende Informationen lieferten. Am Ende gab es von Seiten der Agentur und auch vom neuen Hoster keine wirklichen Lösungen.
Wir stiegen also in die Analyse des Systems ein.
Folgende Eckdaten wurden gesammelt:
- Der Shop verwendet Shopware 5
- Der Shop lief bei dem neuen Anbieter auf einen Server (DB Server und Webserver zusammen)
- Der Shop hat zu Spitzenzeiten 100 gleichzeitige Besucher (> 1.3 Millionen Seitenanfragen pro Tag)
- Der Shop verwendet Redis als Cache Backend
- Der Shop läuft auf einem dedizierten Server mit Nginx als Webserver
- Der Shop läuft auf einem dedizierten Server mit 32 CPU Kernen und 128GB RAM
Als wir die Infos zu dem Server erhalten haben, hat uns gewundert wieso ein so wichtiger und umsatzkräftiger Shop nicht auf einem redundanten System läuft. Ein einfacher Hardwareausfall wie ein defekter RAM Speicher, CPU oder Mainboard würden für einen Stillstand des kompletten Shops für längere Zeit sorgen.
Da der Shop des Kunden bei uns bis dato immer auf einem hochverfügbaren Cloudsystem lief, hat uns diese Eintscheidung des Kunden doch sehr gewundert.
Als erstes haben wir eine Bestandsaufnahme der Performance gemacht.
Bei dem ersten Test haben wir die Geschwindigkeit der Startseite des Shop gemessen. Wir verwenden dazu https://loader.io .
Loader.io kann viele verschiedene Zugriffe mit unterschiedlichen IP Adressen auf eine Zielseite simulieren und die Ergebnisse darstellen:
Der Test war ernüchternt. Zugriffzeiten von über 1.5 Sekunden und bereits bei wenigen Zugriffen war es dem Server nicht mehr möglich zu antworten. Es kam zu Timeouts.
Wir haben eine Testinstanz des Shopware Shops auf unserem Shopware Hosting Demoserver installiert um zu sehen, ob der Shop selbst ggf. ein Problem aufweist. Nach einigen Konfigurationen wie z.B. MySQL Optimierungen, Redis Konfigurationen, PHP-FPM Anpassungen etc. lief der Shop auf unserer Hardware sehr performant:
Durchschnittliche Ladezeiten von unter 500ms lagen in dem Bereich, den wir für diesen Shop erwartet haben.
Uns war schleierhaft, warum das Ergebnis bei dem neuen Hoster nicht erzielt werden konnte und auch offenbar niemend dort bereit war, das Problem weiter zu verfolgen.
Trotzdem war das Ziel der Analyse zu dem Zeitpunkt noch, herauszufinden warum es auf dem Shopware spezialisiertem Hoster nicht in zufriedenstellender Performance funktionierte.
Zu den Eckdaten unseres Systems:
- VMWare Enterprise Cloudsystem mit voller redundanz und einer Verfügbarkeit von 99,99%
- 10GBit Netzwerkverbindungen für die Cloudplattform intern und extern
- 16 Kerne, 16GB RAM
- DB Server und Webserver auf einem System (wegen der Vergleichbarkeit)
- Redis Server als Cache
- NGinx als Reverse Proxy und Apache 2.4 als Backend Server mit PHP-FPM
- Shopware optimierter Cloudserver
Normalerweise würden wir einen Shop dieser Größenordnung auf einem System mit getrennten DB- und Webserver installieren, jedoch wollten wir eine Vergleichbarkeit von unserem System und dem System vom neuen Hoster erreichen. Daher haben wir es so installiert, wie der andere Anbieter.
Nach einigen weiteren Tests konnten wir das System des NGinx Hosting Spezialisten nicht auf unsere Performance anheben. Vom Anbieter und der Agentur kamen leider auch keine brauchbaren Informationen. Der Support war anscheinend auch sehr schwierig. Etwas was aus unserer Sicht im Bereich Shophosting nicht sein darf.
Um den Shopware Shop und ggf. irgendwelche besonderheiten mal komplett auszuschließen, haben wir einfach eine phpinfo auf unserem Server und den des neuen Hosters abgelegt und einen Performancetest durchgeführt:
Hurra, dies war tatsächlich der erste Test, den der Server des anderen Anbieters ohne Fehlermeldung beantworten konnte. Die durchschnittliche Zeit von 624ms war nicht begeisternd.
Wir haben den Test auf unserem System durchgeführt:
Die durchschnittliche Ladezeit einer phpinfo Seite war auf unserem System bereits über 40% schneller als auf dem System des NGinx Spezialisten.
An der Stelle haben wir aufgehörrt nach Problem im Shop oder in den Einstellungen zu suchen. Das andere System hat offenbar ein Leistungsproblem da es bereits unserem System mit 16 Kernen und 16GB RAM bei sowas einfachem wie einer phpinfo Seite weit unterlegen war.
Da wir im ständigem Kontakt mit dem Kunden waren, haben wir diese neue Info an ihn kommuniziert. Wir sind somit dazu übergegangen, das Shopware System auf unserem Servern mit größtmöglicher Performance zur Verfügung zu stellen und haben aufgehört die Problem des anderen Anbieter zu suchen da sich dieser offenbar wenig lösungsorintiert gezeigt hat.
Auch Tests ohne Redis Cache zeigten, dass unser System mit einer durchschnittlichen Ladezeit von weit unter einer Sekunde theoretisch auch ohne Cache in der Lage wäre, eine große Anzahl von Kunden zu bedienen. Dies wird ggf. notwendig wenn aufgrund einen Produktupdates ein löschen des Caches im Betrieb notwendig ist. In dem Fall müssen die Seiten schnell aufgebaut werden können um den Cache schnell zu erneuern.
Im weiteren Verlauf wurde bei unseren Tests langsam die Anzahl der Benutzer pro Minute erhöht. 250 Benutzer pro Minute sollten eigentlich noch keine große Herausforderung für ein vernünftig konfiguriertes Shop Hosting System sein.
Bei 400 Benutzer pro Minute mit aktiviertem Redis Cache sieht noch alles gut aus:
Bei 600 Clients pro Minute und deaktiviertem Cache sieht die Sache schon anders aus:
Hier zeigt sich, dass ein System mit DB- und Webserver sich gegenseitig behindert. Ohne Cache wird der DB Server intensiv genutzt. Die Performance, die hier benötigt wird, fehlt dem Webserver, Am Ende steht das System. Dies ist auch nur bedingt durch mehr Kerne oder mehr RAM aufzufangen. Am Besten trennt man die beiden Systeme und verwendet zwei Server. So ist eine gegenseitige Behinderung ausgeschlossen. Da unsere Cloudserver sowohl intern als auch extern hochperformante 10GBit Verbindungen verwenden ist sichergestellt, dass die Daten der Datenbank mit bestmöglicher Geschwindigkeit zum Webserver geliefert werden. Ebenfalls hilft die Trennung von Web-und DB Server bei späteren Skalierungen, weitere Webserver über einen Loadbalancer zu installieren.
Nach der Installation des dedizierten DB Servers lief auch der Test mit 600 Clients / Minute ohne Cache problemlos durch. So stellen wir uns das bei einem Hosting Spezialisten und Shopware Hosting Paket vor. Auch der Kunde war begeistert.
Nach der Aktivierung des Caches ergaben sich wirklich sehr gute Ladezeiten:
Nach dem bis jetzt alles super lief, wollten wir unser Glück herausfordern und versuchten eine Test mit 1000 Clients / Minute:
Hier liegen offenbar die Grenzen des Systems. Ab 1000 Clients / Minute muss über ein Lastenausgleich nachgedacht werden d.h. es werden mehrere Webserver installiert, die im Backend auf den DB Server zugreifen.
Dies entspricht auch der heutigen Philosophie. Man versucht seine Systeme nicht mehr in die Höhe wachsen zu lassen sondern in die Breite. Lieber 2 Webserver mit je 12 Kernen statt ein Webserver mit 32 Kernen. Es gibt Komponenten im System, die können mit zusätzliche CPUs und RAM nicht hoch skaliert werden (Controller, Bussystem etc.).
Wenn der Kunde diese Zugriffszahlen erreicht sind wir gerüstet das System schnell auf ein Loadbalancing aufzurüsten.
Wir freuen uns, dass wir den Kunden auf diese Weise wieder in unser Rechenzentrum zurückholen und mit unserem Service und System zeigen konnten, dass wir in einer höheren Liga spielen als selbsternannte norddeutsche Spezialisten für NGinx Hosting.
Wenn auch Sie unzufrieden mit Ihren Shopware Hosting sind oder Fragen zu professionellen und performanten Shop Hosting Servern haben, kommen Sie gerne auf uns zu. Wir freuen uns über Ihre Anfrage und stellen Ihnen gerne ein Demosystem zum Testen zur Verfügung.