Im Regelfall dauert das Speichern eines Entries in Craft CMS nur Bruchteile von Sekunden. In einem relativ großen Projekt konnten wir jedoch vor Kurzem sehr lange Speicherzeiten beobachten (teilweise bis zu 10 Sekunden). Zuerst wussten wir nicht, warum genau dies passiert. Logischerweise lassen mehrere Versionen eines Entries, die in der Datenbank gespeichert werden, diese auch exponentiell wachsen (etwas, das man nicht auf die leichte Schulter nehmen sollte), aber dies sollte eigentlich keine Auswirkungen darauf haben, wie lange es dauert, einen Entry zu speichern.

Um zumindest die Datenbankgröße etwas in Schach zu halten, haben wir uns zuerst entschlossen, die Anzahl an Revisions, die vom CMS gespeichert werden, zu limitieren. Standardmäßig speichert Craft 50 Revisions in der Datenbank – diesen Wert haben wir jedoch auf 10 Revisions in unserem Live-System und 5 Revisions in unserem Stage-System verringert. Dies kann problemlos durch den Parameter maxRevisions in der Konfigurations-Datei von Craft CMS erreicht werden, den man einfach auf die jeweilige Anzahl der Revisions setzen muss. Obwohl dieser Ansatz problemlos funktionierte, löste er leider nicht unser eigentliches Problem. Nach einer sorgfältigen Analyse, was genau beim Speichern eines Entries passiert, konnten wir den Haken an der Sache schließlich finden: wenn eine neue Version gespeichert wird, die die Anzahl der Revisions eines Entries über das eingestellte Limit steigen lässt, wird zuerst die älteste Revision gelöscht, bevor die neue Version gespeichert wird.

Dies macht natürlich absolut Sinn (da das Limit sonst überschritten werden würde), verursacht jedoch erhebliche Probleme, wenn ein Entry zu groß ist oder viele verschiedene Content Builder-Elemente enthält. Nach der Entdeckung des Problems hatten wir sofort den Vorschlag, die alte Revision einfach mit einem Queue Job löschen zu lassen (https://github.com/craftcms/cms/issues/5902). Nicht ohne Stolz können wir verkündigen, dass es diese Idee in die nächste Version von Craft CMS (Version 3.5, Veröffentlichung vermutlich im Sommer) geschafft hat!

Leider konnten wir bezüglich unseres Problems nicht bis zur Veröffentlichung von Craft CMS 3.5 warten, weswegen wir eine kleine Übergangslösung implementieren mussten: wenn man maxRevisions auf Null setzt, dann werden unlimitierte Revisions gespeichert und keine Revisions gelöscht. Diese Umstellung alleine hätte katastrophale Auswirkungen – zum Glück wurde erst vor Kurzem ein neues Craft CLI Command namens utils/prune-revisions vorgestellt, das alle Revisions über einem gewissen Limit löscht. Dies war perfekt für unsere Zwecke, denn das Einzige, was wir danach noch tun mussten, war die Einrichtung eines Cron Jobs, der auf unserem Live-System alle Versionen, die über dem Wert von 10 liegen (und auf unserem Stage-System alle Versionen, die über dem Wert von 5 liegen) löscht – und fertig!