Ich fahre diverse Installationen von Shopware auf verschiedenen Systemen. Den Cache Warmup nutze ich aber so gut wie nie da er mir immer sehr langsam vorkam als ihn 1-2x am Tag laufen zu lassen.
Auf einem neueren System mit NVMe SSDs und ZFS Pools habe ich versucht noch mehr zu optimieren, komme aktuell aber nur auf Werte im Bereich von ~7Minuten für 1.000 Produkte beim Cache Warmup in der Konsole, was mir immer noch sehr lang vorkomt.
In der Datenbank sind rund 100.000 Produkte, alle mit Bildern, Datenblättern, technischen Daten (Eigenschaften) versehen, aber keine Varianten Artikel.
Als Datenbank kommt MariaDB zum Einsatz, Webserver Apache2 mit PHP-FPM (7.0.29) und mpm_event. DB und Frontend sind getrennte VMs mit DIRECT ohne WriteThrough, also geringst möglicher Verlust.
Webserver hat 64GB RAM mit 4 Kernen, DB Server hat 32GB RAM mit 4 Kernen. CPU im Host ist ein Xeon E5-1650 v3 3,5GHz mit 12 Kernen.
FPM Config
pm = dynamic
pm.max_children =1000
pm.start_servers =4
pm.min_spare_servers =2
pm.max_spare_servers =4
pm.max_requests =1000
MariaDB Config
join_buffer_size = 1M
table_open_cache = 4000
innodb_buffer_pool_size = 5G
innodb_log_file_size = 1G
innodb_buffer_pool_instances = 5
Mir kommt der Warmup basierend auf den Daten immer noch ziemlich schnarchig vor. IMO habe ich aber auch mal irgendwo gelesen das die WarmUp Methode eh nicht so optimal umgesetzt ist.
Wie handhabt ihr das mit „größeren“ Shops aufgrund dieser Menge an Artikeln?
Hi,
zum Hintergrund: Der Warmup arbeitet ja wie ein regulärer Shopbesucher. Es werden als die SEO-URLs aus der Datenbank nacheinander aufgerufen.
Daher wird man auch so viel nicht an der Performance rausholen können. Generell ist von unserer Seite aber eine Verbesserung geplant, wie z.B. wichtige URLs zuerst aufwärmen und ggf. Aufrufe parallel etc. - Aktuell gibt es da aber keine andere Möglichkeit.
Allgemein ist es ja auch so, dass es dieses „Aufwärmen“ auch in älteren Versionen gar nicht gab. Viele Shops (auch höher frequentierte) arbeiten so, dass zu sehr ruhigen Zeiten der Cache geleert wird (wenn es überhaupt erforderlich sein sollte, dieses manuell zu machen). Dann aber z.B. auch gar nicht aufgewärmt wird, sondern das praktisch durch die ersten Besucher passiert und der Cache sich somit langsam von alleine wieder aufbaut. Je nachdem wir performant der Server ist, sind für den ersten Besucher die Aufrufe etwas langsamer. Das müsste man testen, wie viel langsamer es tatsächlich ist - evtl. kann man auf den Prozess des Aufwärmens dann sogar ganz verzichten.
Sebastian
@SebastianKlöpper Ist es aber auch z.B. Absicht das der WarmUp selbst inaktive Artikel aufwärmt? Hier könnte man auch noch priorisieren oder einstellbar machen das nur aktive Artikel gewarmupped (sweetes Word) werden sollen.
Je nachdem wie viel man an seinem Shop macht, muss man halt leider öfters den Cache leeren weil Änderungen sonst erst weiß der Geier wann auftauchen. Einige Änderungen triggern ja leider nicht das der Inhalt im Cache als „veraltet“ markiert wird damit der nächste Aufruf den Cache für diese View aktualisiert.
Ist es aber auch z.B. Absicht das der WarmUp selbst inaktive Artikel aufwärmt?
Ja. Beim Warm-Up wird nach den SEO-URLs vorgegangen. Es werden alle aktiven URLs aus der Tabelle s_core_rewrite_urls aufgerufen. Das Warm-Up Script weiß gar nicht, ob der Artikel da ist bzw. aktiv ist oder nicht, da es nur nach den zur Verfügung stehenden URLs geht.
Lassen wir per Cron Job nachts durchführen, daher ist es egal wie lange es dauert.