Kevin Adametz
6a34ab48ee
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>
28 lines
1.1 KiB
PHP
28 lines
1.1 KiB
PHP
<?php
|
|
|
|
return [
|
|
|
|
/*
|
|
|--------------------------------------------------------------------------
|
|
| Ereignis-Log (Aufrufe und Shares)
|
|
|--------------------------------------------------------------------------
|
|
|
|
|
| `press_release_events` nimmt seit dem Umbau des Aufruf-Zählers jeden
|
|
| einzelnen Seitenaufruf auf und wächst damit unbegrenzt mit dem Traffic.
|
|
| Die Gesamtzahl steckt nach der Aggregation in `press_releases.hits` und
|
|
| bleibt vom Aufräumen unberührt — begrenzt wird nur, wie weit der
|
|
| ZEITLICHE VERLAUF zurückreicht.
|
|
|
|
|
| 395 Tage (13 Monate) sind bewusst gewählt: Damit bleibt der Vergleich mit
|
|
| dem Vorjahresmonat möglich, ohne das Log für immer mitzuschleppen. Der
|
|
| Wert bestimmt zugleich die Tiefe der geplanten Absenderansicht
|
|
| (Roadmap 1c.1) — wer dort mehr Historie zeigen will, muss ihn VORHER
|
|
| erhöhen; einmal gelöschte Ereignisse kommen nicht zurück.
|
|
|
|
|
*/
|
|
|
|
'events' => [
|
|
'retention_days' => (int) env('PRESS_RELEASE_EVENTS_RETENTION_DAYS', 395),
|
|
],
|
|
|
|
];
|