Es kommt der Zeitpunkt an dem ein Hostingpaket / VServer oder Rootserver nicht mehr ausreicht um alle Requests schnell abzuwickeln. Bevor hier der Apache oder NGINX schlappt macht, ist das meist die Datenbank (Mysql oder MariaDB) – aber mehr dazu im Beitrag…
Shopware als Applikation
Min Anforderungen
- 4GB RAM
- Dual-Core CPU
Aus Erfahrung mit Hosting Paketen, virtuellen Servern, Root Servern und lokalen System kann ich sagen das Shopware eine sehr hungrige Applikation ist.
Ein kleiner VServer kann schnell mal zu schwitzen beginnen, wenn man einen Shop mit +4 Subshops kompiliert – da steigt die CPU Last nämlich schnell auf 100% bei einem Core – ist die CPU noch schwach auf der Brust und es sind noch einige User auf der Seite auf unterschiedlichen Controllern , viel Spass!
Ich empfehle euren Shop einfach immer zu beobachten und Daten von eurem Hoster oder Google Analytics zu analysieren. Ihr werdet dann schnell sehen ob Ihr aufrüsten müsst oder nicht.
Cluster Definition
Ein Cluster besteht aus mehreren Server Komponenten, welche folgende Ziele verfolgen:
- Redundanz (Ausfallsicherheit durch Spiegelung)
- Performance (mehrere Appserver teilen sich die X Requests auf oder Caching Server kümmern sich getrennt um den HTTP-Cache oder das Session Handling)
Schaubild
Load Balancer
Dieser verteilt die eingehenden Anfragen auf die verschiedenen Appserver.
Beispiel: NGINX, Varnish, HAProxy
HTTP Cache
Speichert vorgefertigte Webseiten zwischen und liefert diese an den Kunden/Nutzer aus, ohne vorher Code auf den Appservern zu verarbeiten.
Beispiel: Varnish oder Redis (in Shopware verfügbar ab der Enterprise Version)
Adminserver
Simpler Server zum Beispiel mit Ubuntu 16.04 LTS und den entsprechenden Shopware Settings. Kann in den meisten Fällen kleiner von der Hardware ausfallen, als die Appserver, da über diesen Server nur weniger Backenduser laufen und API Calls an Shopware (bzw. CLI commands wie z.B. kompilieren etc.)
Appserver
Simpler Server zum Beispiel mit Ubuntu 16.04 LTS und den entsprechenden Shopware Settings – sollte Softwaretechnisch eine exakte Kopie des Adminservers sein . Sollte mehr Leistung als der Adminserver haben, da hier alle Requests der Kunden eingehen, falls diese nicht zum Großteil vom HTTP Cache abgefangen werden.
Elasticsearch (optional)
Eine hochperformante Suchengine (NoSQL) welche für Artikel bereits in der Community Edition verfügbar ist. Shopware vertreibt seit kurzem eine Enterprise Search – diese kann neben den Artikel noch Kategorien, Blogbeiträge, Shopseiten und Einkaufswelten indexieren. Ebenfalls implementiert das Plugin noch eine Backendsuche welche sich bei +30000 Artikeln wirklich bezahlt macht…
Das ganze kann optional hinzugeschaltet werden und ist gerade bei Shops mit vielen Suchanfragen eine gute Investition.
Session Handling
Hier kann man sich zwischen 4 unterschiedlichen Varianten entscheiden:
- File
- Datenbank
- Memcached
- Redis
genaueres dazu findet ihr HIER
Ab einem gewissen Traffic sind File und Datenbank nicht mehr praktikabel – gerade wenn das Session Locking bei der Datenbank Variante angeschaltet ist, werden eure Response Zeiten unterirdisch.
Memcached und Redis kann man in den meisten Fällen ohne Probleme auf einer schon laufenden Maschine installieren. Beispielsweise auf der Maschine des Loadbalancers oder einer Instanz auf der nur ein Gitlabserver läuft etc.
Zu bemerken ist, dass Redis im Gegensatz zu Memcached kein Session Locking kann – dies führt allerdings in einem Produktivsystem auch bei Memcached zu extremen Problemen. Weswegen wir dies ausgeschaltet haben – daher kann man sich die Mühe sparen und gleich zu Redis wechseln. Da das sowieso performanter ist als Memcached (nicht zu verwechseln mit Memcache!)
Datenbank Server
Simpler Server zum Beispiel mit Ubuntu 16.04 LTS und meist mit einer HIGH I/O Ausstattung (NVMe SSDs). Man sollte hierbei auf einen Querycache setzen (bis 5.6 noch supported) oder gleich auf MariaDB setzen (auch wenn nicht offiziell supported).
Statische Daten
Ordner welche in Shopware einen Großteil des Speichers belegen, sollten auf ein NFS oder CDN ausgelagert werden. Man möchte gerade bei Clustersetups mit +2 Appservern vermeiden die Daten immer wieder zu syncen. Mit einem NFS oder CDN stehen die Daten allen Appservern zur Verfügung und werden im Backend vom Adminserver verwaltet.
NFS (Network File System)
Beim NFS werden die Daten auf einer vom Hoster speziell zur Verfügung gestellten Cloud gespeichert. Die Appserver und der Adminserver werden dann auf diesen Ort gemounted (bei Shopware in den meisten Fällen der /media/ Ordner).
CDN (Content Delivery Network)
Das CDN stellt Daten an verschiedenen Knotenpunkten im WWW zur Verfügung, dadurch können Daten direkt von diesen Knotenpunkten an den Kunden/Nutzer gesendet werden. Das spart in den meisten Fällen Zeit durch die kürzere Strecke und die Anfragen können durch die parallele Abarbeiten schneller bearbeitet werden. Mehr dazu HIER
Shopware hat für diese Zwecke File System Adapters mit denen Ihr die Inhalte/Bilder schnell auf das CDN eurerer Wahl schieben könnt.
Cluster ja oder nein?
Ihr seid euch nicht sicher, ob Ihr ein Cluster Setup benötigt? Schreibt mich gerne an und ich kann mir ein Bild vom aktuellen Stand machen.
Oftmals reicht schon ein kurzer Blick in Google Analytics ein PHP Analyse Tool wie New Relic oder Tideways und 2-3 Tests auf dem entsprechenden Server um eine Aussage zu treffen ob es notwendig ist aufzustocken.
Falls möglich könnt Ihr euren Hoster auch vorab fragen ob Ihr kostenfrei ein besseres Setup zu eurem jetzigen VServer / Root Server testen könnt. Eventuell reicht das am Anfang noch aus um bessere Response Zeiten zu bekommen.
Fast nichts ist im Ecommerce wichtiger als eine schnelle Seite – die CR steigt mit einer besseren Perfomance immer an.
Hoffe der Beitrag hat einigen geholfen. Wenn Ihr Interesse an einem Shellscript für das deployen vom Adminserver auf die Appserver habt, schreibt mir in die Kommentare 😉