Wie wir die Business-Members-Seite ~100x schneller gemacht haben

Was die Seite macht

Die Business-Members-Seite listet jedes Mitglied eines Unternehmens auf. Neben Name und Rolle zeigt das Grid fünf berechnete Finanzspalten:

Keiner dieser Werte wird irgendwo als fertige Zahl gespeichert. Sie werden aus den rohen Arbeitseinträgen jedes Mitglieds berechnet, den einzelnen Schichtdatensätzen in unserer Redis-Datenbank. Eine Grid-Zeile zu erzeugen bedeutet, Profil und komplettes Arbeitsjahr eines Mitglieds zu laden, Stunden in regulär und Überstunden aufzuteilen und Bruttoentgelt zu summieren. Multipliziert mit jedem Mitglied des Unternehmens ist das die Arbeit der Seite.

• Brutto seit Jahresbeginn — gesamte Einnahmen in diesem Jahr
• Gesamtstunden — alle in diesem Jahr gearbeiteten Stunden
• Reguläre Stunden — Stunden zum Standardsatz
• Überstunden — Stunden über dem regulären Schwellenwert
• Trailing baseline — rollierende Referenzzahl für Vergleiche

Das Problem, Teil 1 — Das N+1-Abfragemuster

Die ursprüngliche Implementierung machte eine Abfrage für die Mitgliederliste und dann, für jedes von ungefähr 100 Mitgliedern, separate, sequentielle Round-Trips zu Redis: einen für das Profil und weitere für das vollständige Jahr an Arbeitseinträgen.

Kleine Unternehmen mit wenigen Mitgliedern waren weitgehend nicht betroffen; die gestapelte Latenz wird erst sichtbar, wenn Organisationen auf dutzende oder hunderte Mitglieder wachsen und Round-Trips pro Mitglied zu Sekunden Serverzeit anwachsen.

Das ist das klassische “N+1”-Muster: eine Abfrage für die Liste, dann N weitere Abfragen nacheinander für die Elemente darin. Einzelne Redis-Lookups sind schnell, deutlich unter einer Millisekunde tatsächlicher Arbeit, aber jeder Round-Trip zahlt auch feste Netzwerklatenz. Sequentiell überlappen diese Kosten nicht; sie stapeln sich linear.

Die Datenbank war nie der Engpass. Das Gespräch mit der Datenbank war es.

Das Problem, Teil 2 — Alles bei jedem View neu berechnen

Der zweite Fehler verstärkte den ersten. Die gesamte Payroll-Mathematik, ein Jahr Arbeitseinträge in reguläre und Überstunden zu teilen, Brutto seit Jahresbeginn zu berechnen, die trailing baseline abzuleiten, für jedes Mitglied, wurde bei jedem einzelnen Seitenaufruf von Grund auf neu berechnet.

Arbeitseinträge ändern sich nicht sehr häufig. Zwischen zwei aufeinanderfolgenden Aufrufen der Members-Seite sind die zugrunde liegenden Daten fast immer identisch. Trotzdem zahlte jeder Besuch die vollen Kosten für Ergebnisse, die kurz zuvor bereits berechnet und dann verworfen wurden.

Zusammen erzeugten die beiden Fehler etwa 1,8 Sekunden Serverzeit pro Seitenaufruf, gemessen mit PayCal Lens, unserer integrierten Server-Timing-Instrumentierung.

Der Fix, Teil 1 — Redis Pipelining

Redis unterstützt Pipelining: einen Stapel Befehle in einem einzigen Round-Trip senden und alle Antworten zusammen erhalten. Statt eine Frage zu stellen, zu warten, die nächste zu stellen und wieder zu warten, stellt der Server nun alle Fragen auf einmal.

Wir haben die Batch-Lookup-Methode Database::pipelineHgetall() ergänzt und das Members-Grid darauf umgestellt. Alle Profil-Lookups werden in einem Round-Trip gesammelt und alle Work-Entry-Lookups in einem weiteren, statt ein Round-Trip pro Mitglied und Datentyp.

// Before - one round-trip per member, latency stacks linearly
foreach ($memberIds as $id) {
    $profiles[$id] = Database::hgetall($profileKey($id));
}

// After - one round-trip for the whole batch
$profiles = Database::pipelineHgetall(array_map($profileKey, $memberIds));

Diese Änderung allein reduzierte hunderte sequentielle Latenzzahlungen auf wenige.

Der Fix, Teil 2 — Ein materialisierter Cache

Pipelining macht die Berechnung günstiger zu füttern; der zweite Fix vermeidet, die Berechnung überhaupt zu wiederholen. Wir haben BusinessMembersCache eingeführt, einen serverseitigen Cache, der die fertig berechneten Grid-Daten, also die Finanzzusammenfassungen pro Mitglied, in Redis speichert.

Zwei Regeln steuern die Cache-Aktualität:

• 5-Minuten-Ablauf. Jedes gecachte Grid läuft automatisch nach 5 Minuten ab und begrenzt damit, wie alt die Daten maximal sein können.
• Explizite Invalidierung bei Änderungen. Jede memberbezogene Änderung, Rollenupdate, hinzugefügtes oder entferntes Mitglied, löscht das gecachte Grid sofort. Nach relevanten Edits wird der Cache sofort invalidiert, sodass der nächste Request frische Daten erzeugt.

Mitgliedsidentität und Berechtigungsprüfungen werden bewusst nicht gecacht. Jeder Request durchläuft weiterhin den vollständigen Access-Control-Pfad; nur die teure Finanzarithmetik wird wiederverwendet.