Bisher lief pro Seitenaufruf ein UPDATE press_releases SET hits = hits + 1 im Request. Auf der über 1 GB großen Tabelle blockiert dieser Schreibzugriff, sobald dort eine Schemaänderung läuft — die wartenden Requests belegten dabei PHP-FPM-Worker und DB-Verbindungen, bis die ganze Seite stand. Der Request schreibt jetzt nur noch in die kleine Append-Tabelle press_release_events, und selbst dabei wird jeder Fehler geschluckt und gemeldet: Ein Aufruf-Zähler darf eine Seite niemals langsamer oder kaputt machen. Die Summierung in press_releases.hits übernimmt gebündelt der Scheduler. Der Fortschritt läuft über eine Wasserstandsmarke (höchste bereits verbuchte Event-ID) statt über einen Zwischenspeicher, damit bei einem Neustart kein Aufruf verloren geht. Zähler und Marke werden je Durchgang gemeinsam committet — sonst wäre nur der Durchgang wiederanlaufsicher, nicht der Abbruch darin, und der nächste Lauf verbuchte dieselben Aufrufe doppelt. Eine Migration setzt die Marke beim Deploy auf den Ist-Stand; ohne sie würde der erste Lauf den gesamten Altbestand ein zweites Mal aufaddieren. Weil das Log damit mit dem Traffic wächst und als einzige Log-Tabelle des Systems keine Bereinigung hatte, begrenzt press-releases:purge-events es auf einen Aufbewahrungszeitraum (Default 395 Tage = 13 Monate, damit der Vorjahresmonats-Vergleich möglich bleibt). Gelöscht wird ausschließlich unterhalb der Wasserstandsmarke — alles darüber ist noch nicht in hits verbucht und wäre sonst dauerhaft verloren. Fehlt die Marke, bricht der Lauf ab, statt zu raten. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| factories | ||
| migrations | ||
| seeders | ||
| .gitignore | ||