technik: Aufrufe über ein Ereignis-Log zählen statt im Request

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>

config/press_releases.php

@@ -0,0 +1,28 @@
+<?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),
+    ],
+
+];