3. Über Jonas
● Linux Administrator bei maxcluster
● Fokus auf Performance-Analysen
● Mail: jhuenig@maxcluster.de
● Github: https://github.com/jonashrem
● Twitter: @jonashrem
5. Warum Performance-Optimierung?
● Ziel eines Shopbetreibers: Steigerung der Conversion Rate
● Unmittelbarer Zusammenhang zwischen der Conversion Rate und der Performance eines
Onlineshops
● Ein performanterer Shop kann mehr Besucher gleichzeitig bedienen
→ Performance-Optimierung beginnt beim Hosting!
6. Einordnung von Ladezeiten
Verschiedene Arten von Ladezeiten sagen Unterschiedliches aus!
Es ist wichtig zu verstehen, …
● was gemessen wird
● unter welchen Bedingungen gemessen wird
● wodurch Ladezeit beeinflusst wird
● wie die Ladezeit vor/nach Änderungen gemessen wird
7. TTFB (Time To First Byte)
● Zeit bis zur Antwort des Servers
● Bezieht sich nur auf den eigentlichen Seitenaufruf
PHP-Ausführungszeit
● Ausführungszeit der Anwendung auf dem Server (ohne Netzwerk)
Gesamtladezeit
● Enthält Bilder, Javascript & CSS
Definition von Ladezeiten
15. ● Full-Page-Cache für
dynamische Webseiten
● Wird dem Shop
vorgeschaltet
● Cacht komplette Webseite
im Arbeitsspeicher
● Kann Ladezeit stark
verbessern
● Dynamische Inhalte
werden über Ajax oder ESI
nachgeladen
Über Varnish
16. Voraussetzungen für die Konfiguration
● Shopware 6.4 oder neuer
● Varnish 6 oder höher
● Redis-Instanz für Tags
● Prüfen, welche Inhalte aus dem Cache kommen!
19. Über Redis
● Key/Value Datenbank
● Speichert Daten für performanten Zugriff im Arbeitsspeicher
● Bringt hohe Geschwindigkeitsvorteile bei parallelen Zugriffen
● Eignet sich daher besonders gut für Session- oder Cache-Inhalte
● Empfohlen besonders für mittlere und große Onlineshops
20. Redis als Datenbank für Shopware-Sessions
● Im Normalfall Speicherung der Sessions durch Shopware 6 auf dem Dateisystem
● Redis liegt als „in memory“-Datenbank im Arbeitsspeicher
● Kann über Symfony-Methoden in Redis verschoben werden
21. Redis als Session-Handler einrichten
● Konfiguration erfolgt über die Symfony-Konfigurationsdatei config/services.yaml:
services:
Redis:
class: Redis
calls:
- method: connect
arguments:
- '%env(REDIS_SESSION_HOST)%'
- '%env(int:REDIS_SESSION_PORT)%'
SymfonyComponentHttpFoundationSessionStorageHandlerRedisSessionHandler:
arguments:
- '@Redis'
● Festlegung von Redis als Session-Handler → Eintragung von Host und Port als
Variablen
22. Redis als Session-Handler einrichten
1. Variablenzuweisung innerhalb der .env, damit die Variablen genutzt werden können:
REDIS_SESSION_HOST=127.0.0.1
REDIS_SESSION_PORT=6380
2. Shopware-Cache leeren, damit Änderungen wirksam werden:
bin/console cache:clear
3. Mithilfe der Redis-Konsole überprüfen, ob die Sessions erfolgreich in Redis
gespeichert werden:
redis-cli -p 6380 MONITOR
23. Redis als Datenbank für Shopware-Cache
● Shopware 6 legt Anwendungscache im Normalfall im Dateisystem ab
● Kann über Symfony-Methoden in Redis verschoben werden
● Pools können einzeln oder komplett in Redis ausgelagert werden
● Größe des Caches prüfen!
24. Redis als Cache-Handler einrichten
● Ablage der Konfiguration für den Cache-Handler in der Datei
config/packages/framework.yaml
● Dafür entweder einzelne Cache-Pools definieren oder Redis als Default Redis für alle
Cache-Pools festlegen
● Als HTTP-Cache wird der Pool cache.http angesprochen:
framework:
cache:
default_redis_provider: "redis://%app.redis.cache.host%:%app.redis.cache.port%"
pools:
cache.http:
default_lifetime: 3600
adapter: cache.adapter.redis
tags: cache.tags
● Alternativ die Konfiguration als Default für alle Pools:
framework:
cache:
app: cache.adapter.redis
default_redis_provider: "redis://%app.redis.cache.host%:%app.redis.cache.port%"
25. 1. Für Übersetzung verwendeter Variablen müssen gesetzte Parameter in die Datei
config/services.yaml integriert werden:
parameters:
app.redis.cache.host: "%env(REDIS_CACHE_HOST)%"
app.redis.cache.port: "%env(REDIS_CACHE_PORT)%"
2. Auf die Werte aus der .env-Datei zurückgreifen:
REDIS_CACHE_HOST=127.0.0.1
REDIS_CACHE_PORT=6379
3. Shopware-Cache mit folgendem Befehl leeren, damit die Änderungen wirksam werden:
bin/console cache:clear
Redis als Cache-Handler einrichten
Bildquelle // Fotograf
27. Datenbankeinstellungen
● Standardeinstellung von MySQL oft schon sehr gut
● Keine Templates aus dem Internet kopieren
● InnoDB Buffer Pool Size an Anwendung anpassen
● Andere Werte nach Bedarf anpassen
28. Queries finden und prüfen
1. Langsame Queries finden
2. Queries optimieren
3. Ausführungsplan mit EXPLAIN prüfen
4. MySQL-Indizes prüfen
31. MySQL Auslastung mit Slow Log prüfen
● Slow Log für begrenzten Zeitraum aktivieren
● Analyse auch mit long_query_time=0 relevant
● Analyse der Slow log mit pt-query-digest
32. MySQL-Auslastung mit Slow Log prüfen
● Über die Slow
Log lassen sich
Queries mit
hohen
Auswirkungen
auf die Laufzeit
finden
34. ● NoSQL-Datenbank mit Fokus auf Suchfunktionen
● funktioniert als Suchengine
Über Elasticsearch
35. ● Erhält Kopie des Produktkatalogs in für Suchen optimierter Form
● beschleunigt die Shopware-Suche
● Voraussetzung für Enterprise-Suche
Elasticsearch und Shopware 6
36. Vorbereitung
1. Datenbank-Tabellen leeren
2. Den Parameters-Block kopieren
3. Den kopierten Parameters-Block in die
Datei des container-Blocks einfügen
4. Anpassungen in der services.xml
vornehmen
5. Shopware-Cache leeren
truncate table enqueue;
truncate table message_queue_stats;
vendor/shopware/elasticsearch/Resources/config/services.xml
config/services.xml
number_of_shards 1
numer_of_replicas 0
mapping.total_fields.limit 50000
php bin/console cache:clear
37. Reindex
Reindex in einer Screen-Session
screen -S elastic
php bin/console es:index
php bin/console messenger:consume -vv
39. Standardverhalten von Shopware 6
● Shopware 6 funktioniert standardmäßig „out of the box“
● Standard-Konfiguration ist nicht immer optimal
● Um nachträglichen Konfigurationsaufwand gering zu halten, ist Admin Worker aktiv
● Admin Worker führt Aufgaben im Hintergrund durch
● Wird nur durch Aktivitäten im Shopware-Backend getriggert
⇒ langsames Backend!
Empfehlung: Deaktivierung des Admin Workers, um stattdessen die Message Queue zu
verwenden
40. Message Queue
● Erlaubt es, Aufgaben asynchron auszuführen
● Kann in MySQL oder RabbitMQ abgelegt werden
● benötigt (einen oder mehrere) Queue Consumer
41. Queue Consumer
● Läuft im Hintergrund und arbeitet Aufgaben ab
● Kann über Cronjob gestartet werden
● Kann über Prozessmanager wie Supervisord oder systemd gestartet werden
42. Admin Worker deaktivieren und Cronjobs einrichten
1. Deaktivierung des Shopware 6 Admin-Workers in der Datei
config/packages/shopware.yaml:
shopware:
admin_worker:
enable_admin_worker: false
2. Start der Dienste Scheduled Task Runner und Message Consumer zur Verwendung
der Message Queue. Konfiguration z.B. via Cronjob:
*/3 * * * * /usr/bin/php /var/www/share/beispiel.de/shopware/bin/console scheduled-task:run --time-limit=120
*/3 * * * * /usr/bin/php /var/www/share/beispiel.de/shopware/bin/console messenger:consume --time-limit=120
→ Beispiel Cronjob-Konfiguration:
● Start der Consumer alle 3 Minuten mit einer Laufzeit von 2 Minuten
● Empfehlung: Kurze Laufzeit, um Memory-Leaks zu vermeiden
43. ● Alternativ: Verwaltung der Dienste Scheduled Task Runner und Consumer durch
Supervisord
● Dazu wird für jeden Prozess eine entsprechende Konfiguration angelegt
● Beispiel für den Scheduled Task Runner:
[program:scheduler]
command=php -dmemory_limit=-1 /var/www/share/beispiel.de/shopware/bin/console scheduled-task:run --time-limit=60
autostart=true
autorestart=true
startsecs=1
stopsignal=TERM
Beispiel-Prozess mit Supervisord: Laufzeit von 60 Sekunden mit einem Memory Limit von
512 MB und automatischem Neustart nach dem Beenden des Prozesses
Supervisor Prozessverwaltung
44. Supervisor Prozessverwaltung
Eine Beispiel-Unit für den Consumer:
[program:consumer]
command=php -dmemory_limit=-1 /var/www/share/beispiel.de/shopware/bin/console messenger:consume --time-limit=60 --memory-limit=512M
autostart=true
autorestart=true
startsecs=1
stopsignal=TERM
ExecStart=/usr/bin/php
46. Zusammenfassung
● Shop-Performance ist wichtig, um Besucher zu halten und eine hohe Besucherzahl zu
bedienen
● Um die Performance zu verbessern, müssen Flaschenhälse zuerst identifiziert und
gemessen werden
● FPC in Varnish bringt einen extremen Geschwindigkeitsvorteil
● Für mittlere und größere Shops lohnt es sich, Sessions und Cache in Redis zu
verschieben
● Ineffiziente Datenbank-Queries können ein Flaschenhals sein
● Elasticsearch kann die Suche stark beschleunigen
● Message Queue statt Admin Worker verwenden
48. Performance-Optimierung bei maxcluster
● Analyse von Flaschenhälsen
● Proaktives Monitoring
● Empfehlungen zu Anwendungsoptimierungen
● Optimierungen von Serverparametern zur Anwendung
● Begleitung bei High Traffic Events
49. Vielen Dank für Ihre
Aufmerksamkeit!
Unsplash // Abed Ismail
50. Weiterführende Lektüre
● Blogartikel zum Thema Webseitenkomprimierung
● Blogartikel zum Thema Profiling mit Tideways
● Blogartikel zum Thema Performance-Optimierung mit Redis
● Blogartikel zum Thema Elasticsearch
● Blogartikel zum Thema Conversion-Optimierung
● geplant: Blogartikel zum Thema Varnish
E-Mail: jhuenig@maxcluster.de
Github: https://github.com/jonashrem
Twitter: @jonashrem
Kontakt Jonas Hünig Kontakt maxcluster
maxcluster GmbH
Lise-Meitner-Str. 1b
33104 Paderborn
Tel.: 05251 / 41 41 30
E-Mail: info@maxcluster.de
Web: maxcluster.de