Nach über 6 Monaten kommt mal wieder was in meinem IT Blog. Leider haben private Projekte mich doch sehr unter Beschlag genommen (unter anderem ein kleiner Blog der sich um das Thema Nachhaltigkeit und Umweltschutz drehen soll -> https://erhalt-statt-wachstum.de ). Aber nun soll wieder monatlich ein Beitrag zum Thema Shopware folgen.
Shopware 6.4.11.1
Neuer DB Index auf customer -> email
Es ist eines dieser Updates die für uns in einem Setup Pflicht waren, da das Login Query bei hohem Traffic blockte und wir damit dann teilweise Slow Transacations im 20-30s Bereich hatten
Nach dem Update sahen die Peaks um 09 Uhr dann wie folgt aus
Performance Optimierungen
Hier hat Shopware einen Workshop / Projekt gestartet um bekannte Probleme zu fixen und unbekannte zu finden (so wie ich mitbekommen habe durch das befeuern der API und Storefront mit Requests). Daraus wurden dann Optimierungen erarbeitet oder Konfigurationsempfehlungen erstellt die Ihr unter Performance Tweaks findet.
Kunde ist eingeloggt / Warenkorb gefüllt
Zusammengefasst: Habt ihr einen Shop in dem eure Produkte immer feste Preise haben und eure Seite für alle frei zugänglich sind etc. – dann macht es keinen Sinn das Seiten nicht gecached werden wenn der Kunde eingeloggt ist oder etwas im Warenkorb hat. Ihr könnt das Array der der http Cache invalidation dann einfach leer übergeben. Ihr merkt dies deutlich in Shops mit +10k Produkte und 3 Sprachen + Canonical Tag aktiv – legt euch mal was in den WK und geht auf die Startseite und dann nochmal ohne.
Mysql statt MariaDB
Hier wird die Empfehlung für MariaDB statt MySQL ausgesprochen. Es wundert mich das hier der Fork von MDB hinterher ist, wäre aber definitiv ein Hinweis wert für Hoster die nur MDB anbieten wie Timme Hosting . Diese werben mit schnellem Shopware 6 Hosting und das könnte sich Aufgrund der starken Nutzung von JSON Types in der DB hier negativ auswirken. Bis natürlich MDB nachzieht, wann das ist kann ich nicht sagen.
shopware.yaml config
Um nicht auf jeden einzelen Fall einzugehen liste ich hier einige config auf die in die showpare.yaml kommen sollten:
Update verbieten und Meldung deaktivieren
Zeigt nicht mehr die nervige „ein Update ist verfügbar“ Flashmeldung an und verbietet ein Update via /admin
showpare:
auto_update:
enabled: falseLocks wegen incrementer
Wenn Ihr viele Update auf Produkte etc. habt und mehrer worker laufen wird der Inkrementer der hoch- und runterzählt welche Messages noch abgearbeitet werden müssen schon mal aufgefallen sein. Den könnt Ihr einfach deaktivieren mit
shopware:
increment:
user_activity:
type: 'array'
message_queue:
type: 'array'Mail Template
Um eine automatische Vervollständigung für die verschiedenen Mailvorlagen in der Administrationsoberfläche zu ermöglichen, verfügt Shopware über einen Mechanismus, der beim Versand der Mail eine Beispielmail in die Datenbank schreibt. Hiermit aktiviert ihr dies.
shopware:
mail:
update_mail_variables_on_send: falseNumber Range
Vermutlich nur interessant für wirkliche HIGH Traffic Shops. Hier wird z.B. für die Bestellnummer von SHOP-001 auf SHOP-002 bei einer Bestellung inkrementiert. Diese Ausführung ist „atomic“ und stellt damit sicher das es kein Nummer zwei mal gibt. Redis handled diese Art von Operation besser und wird daher in diesem Fall empfohlen:
shopware:
number_ranges:
increment_storage: "Redis"
redis_url: 'redis://host:port/dbindex'Wie bei allem gilt – prüft das ganze für euer Setup! Kleiner Shop, geringer Umsatz, kein Redis mit an Board. Dann lohnt es sich vermutlich nicht einen extra Redis Server dafür aufzusetzen.
Umgebungsvariablen
https://developer.shopware.com/docs/guides/hosting/performance/performance-tweaks#.env.local.php
Solltet Ihr ein NFS für das sharen von Files nutzen (z.B. in einem Cluster Setup), ist euch vielleicht in Transaktionen mal aufgefallen dass das laden der .env File doch sehr oft vorkommt. Ist euer Filesystem unter hoher Last kann dies im worstcase auch dazu führen das diese blockiert.
Zusätzlich zum anlegen und syncen (bzw. übergeben in der Pipeline über https://docs.gitlab.com/ee/ci/variables/ ) der .env file anstelle eines Symlinks empfiehlt Symfony und Shopware das nutzen eine .env.local.php File. Diese muss nicht wie die .env Datei analysiert werden. Ihr könnt diese mit symfony/flex geniereren (welches laut Shopware im nächsten Major Release kommen soll) oder per Hand befüllen. Das Format ist denkbar einfach:
<?php
// This file was generated by running "composer dump-env prod"
return array (
'APP_ENV' => 'prod',
'SHOPWARE_ES_HOSTS' => '5.x.x.x:9200',
'SHOPWARE_ES_ENABLED' => '1',
'SHOPWARE_ES_INDEXING_ENABLED' => '1',
'SHOPWARE_ES_INDEX_PREFIX' => 'sw_test',
'SHOPWARE_HTTP_CACHE_ENABLED' => '1',
'SHOPWARE_HTTP_DEFAULT_TTL' => '7200',
'SHOPWARE_CDN_STRATEGY_DEFAULT' => 'id',
'APP_URL' => 'https://test-test.de',
'APP_SECRET' => 'def0000099faf75b0b105229cddd505cc249c25efdea9c131de84a4426145b7c7f89780de6a45070fb755755hsdfhdfhdhd555b62dee7f0cf7e7c4dda039b857',
'INSTANCE_ID' => 'Mz3hFDiLLriSd3i3fgh6rwSIQruRxMf',
'DATABASE_URL' => 'mysql://USER:PW@1.1.1.1:3306/DB',
'SHOPWARE_CACHE_ID' => 'Mz3hFDiLLriSd3gghlwSIQruRxMf',
);
Faul wie ich bin habe ich dem Projekt einfach symfony/flex hinzugefügt, die File generiert und dann wieder resettet.
composer require symfony/flex
composer dump-env prod
git reset --hard && rm -rf vendor && composer install Dokumentation von Symfony gibt es hier
Elasticsearch, Logging und Co.
Die restlichen Themen wie Ihr Elasticsearch und so weiter entnehmt Ihr am besten dem Artikel und ich empfehle euch Froshtools (Github) zu installieren. Damit bekommt Ihr die meisten Tipps zur Optimierung direkt unter admin#/frosh/tools/index/index angezeigt
Der schnelle Weg dahin ist über den Status Button
