Was Shopware im Hintergrund erledigt
33 geplante Aufgaben laufen in 6.7 mit, acht mehr als in 6.6 — davon sechs aus dem Kern. Eine davon sammelt Telemetriedaten.
Nach einem Update fragt selten jemand, was auf dem Server ab sofort regelmäßig läuft. Die Antwort steht in einer Tabelle, und sie hat sich zwischen 6.6 und 6.7 spürbar verändert.
Die Zahlen
| 6.6.10.6 | 6.7.13.1 | |
|---|---|---|
| geplante Aufgaben insgesamt | 25 | 33 |
| davon aktiv eingeplant | 23 | 31 |
| neu, roh gezählt | 8 | |
| davon aus eigenen Plugins | 2 | |
| neu im Kern | 6 | |
| entfallen | 0 |
Die beiden ausgeschlossenen sind pixup.cheapest_price.index_task und
pixup.sitemap_task — sie stammen aus unseren eigenen Erweiterungen und haben
in einem Kernvergleich nichts zu suchen.
Die sechs neuen Kernaufgaben
| Aufgabe | was sie offensichtlich tut |
|---|---|
telemetry.collect_periodic_metrics | erhebt periodisch Kennzahlen der Installation |
app.system_heartbeat | meldet App-Systemen, dass der Shop lebt |
customer.cleanup_customer_recovery | räumt abgelaufene Passwort-Wiederherstellungen ab |
media.cleanup_corrupted_media | entfernt Medien, deren Datei fehlt |
payment_token.cleanup | räumt verbrauchte Zahlungs-Token ab |
translation.update | zieht Übersetzungen nach |
Drei davon sind Aufräumarbeiten, die vorher liegengeblieben sind — das ist schlicht gut. Zwei betreffen Apps und Übersetzungen. Eine sticht heraus.
Die eine, über die man reden sollte
telemetry.collect_periodic_metrics ist in 6.7 neu. Der Name sagt, was sie
tut: Sie sammelt in einem festen Takt Kennzahlen.
Was wir gemessen haben: dass es die Aufgabe gibt, dass sie in der Standardinstallation eingeplant ist, und dass sie in 6.6 nicht existierte.
Was wir nicht gemessen haben: welche Kennzahlen konkret erhoben werden, wohin sie gehen und ob sich das abschalten lässt, ohne anderes zu brechen. Das ist eine eigene Untersuchung, und wir stellen hier keine Behauptung auf, die wir nicht belegt haben.
Was daraus folgt: Wer in einem regulierten Umfeld arbeitet oder schlicht wissen will, was sein Shop nach außen meldet, sollte diese Aufgabe kennen — und die Frage stellen, bevor sie jemand anders stellt.
Der Punkt, der jedes Mal unterschätzt wird
Ohne laufenden Worker passiert nichts davon. Die Aufgaben werden eingeplant, der Zeitpunkt verstreicht, und ausgeführt werden sie erst, wenn ein Message-Consumer läuft.
Das ist die häufigste Ursache für eine ganze Klasse von Symptomen, die nach etwas anderem aussehen:
- Ein Preis ändert sich im Backend und bleibt in der Liste alt — der Indexer lief nicht.
- Eine Sitemap ist Wochen alt — die Erzeugung lief nicht.
- Papierkorb und Wiederherstellungsanfragen wachsen unbegrenzt — das Aufräumen lief nicht.
Der schnellste Test: In der Administration unter den geplanten Aufgaben steht je Aufgabe der Zeitpunkt der letzten Ausführung. Liegt der bei mehreren Aufgaben weit zurück, ist nicht die Aufgabe das Problem, sondern der Worker.
Was wir nach einem Update prüfen
- Läuft der Worker? Erst danach lohnt jede andere Frage.
- Welche Aufgaben sind neu und aktiv? Nach einem Sprung auf 6.7 sind es sechs, die es vorher nicht gab.
- Sind neue Mail-Vorlagen dazugekommen? Nach einem Sprung auf 6.7 sind es fünf, und sie tragen das Standardlayout — Welche Mails Shopware selbst verschickt.
- Gibt es Aufgaben aus Erweiterungen, die nach dem Update nicht mehr auftauchen? Das wäre ein Hinweis, dass eine Erweiterung still ausgefallen ist — eine Fehlerklasse, die wir an einem eigenen Fall gemessen haben: wenn der Shopware-Kern eine Plugin-Route verdrängt.
- Passen die Intervalle zum Betrieb? Eine Aufgabe, die stündlich läuft und jedes Mal zehn Minuten braucht, ist kein Wartungsfenster, sondern Dauerlast.
Grenzen dieser Messung
Gezählt wurde die Aufgabenliste zweier frisch aufgesetzter Installationen mit Demodaten. Über Laufzeit, Last und tatsächliche Wirkung der einzelnen Aufgaben sagt das nichts — dafür braucht es einen Shop mit echten Daten und einen Beobachtungszeitraum.
Ebenso wenig sagt es etwas über Aufgaben, die Ihre Erweiterungen mitbringen. Unsere zwei haben wir hier ausgeschlossen; Ihre kommen zu den 33 dazu.
Wenn Sie den Betrieb danach sauber aufstellen wollen, gehört das zu Shopware-Support.
Häufige Fragen
- Was ist eine geplante Aufgabe in Shopware?
- Ein wiederkehrender Auftrag, den der Message-Worker in einem festen Intervall ausführt — etwa das Aufräumen alter Datensätze oder das Neuberechnen eines Index. Sie stehen in der Tabelle scheduled_task mit Intervall und Status.
- Was sammelt telemetry.collect_periodic_metrics?
- Die Aufgabe erhebt periodisch Kennzahlen der Installation. Wir haben ihre Existenz und ihren Status gemessen, nicht den Inhalt der Übertragung — was genau gesendet wird, ist eine eigene Untersuchung.
- Laufen die Aufgaben ohne Worker?
- Nein. Ohne laufenden Message-Consumer werden sie nur eingeplant und nie ausgeführt. Das ist die häufigste Ursache dafür, dass ein Index veraltet ist oder Aufräumaufgaben nie greifen.
- Kann ich Aufgaben abschalten?
- Ja, über den Status in der Tabelle oder über die Administration. Vorher lohnt der Blick, was die Aufgabe tut — manche halten Indizes aktuell, deren Fehlen erst Wochen später auffällt.