Eine Seite, Dutzende Datenbankaufrufe
Eine Listenseite, die früher schnell war, braucht jetzt eine oder zwei Sekunden, und es wird schlimmer, je länger die Liste wird. Jede einzelne Abfrage sieht in Ordnung aus, wenn du sie prüfst. Zehn Einträge sind kein Problem, hundert schon.
Warum es schwer zu sehen ist
Das ist ein N+1, und es entsteht innerhalb eines Renderings: irgendetwas holt eine Liste und holt dann pro Eintrag einen zugehörigen Datensatz. Jede Abfrage ist tatsächlich schnell — deshalb findet eine Zeitmessung pro Anfrage es nicht und deshalb übersteht es das Review: der Code liest sich völlig vernünftig. Falsch ist allein die Anzahl.
Es kommt meist mit einem Refactoring und nicht mit einer Funktion. Ein Laden in eine Komponente zu verschieben, die einmal pro Zeile gerendert wird, ist eine Änderung von einer Zeile und macht aus einer Abfrage so viele, wie du Zeilen hast.
Was Sixty dagegen tut
Datenbankaufrufe werden pro Rendering gezählt und über Releases hinweg verglichen. Der Befund lautet also „diese Operation machte eine Abfrage pro Rendering und macht jetzt vierzehn, seit diesem Deployment“ statt einer Latenzzahl, die du interpretieren musst. Die Stack-Frames kommen mit, das verantwortliche Rendering ist damit benannt.
Diese Belege gehen über MCP an deinen Coding-Agenten: die Abfrage, die Frames, die Zahlen davor und danach, und welche untergeordneten Aufrufe die Änderung ausmachen.
Was es nicht tut
Aufrufe pro Rendering zu zählen braucht einen Server-Agenten, und den gibt es für Node, Python, Go, Ruby und PHP — aber nur Node bekommt es ungefragt. Seine Build-Transformation öffnet von allein einen Span pro exportierter async-Funktion; überall sonst markierst du den Code, der die Messung wert ist (ein Dekorator in Python, zwei Zeilen in Go, ein eingebundenes Modul in Ruby, ein Aufruf in PHP), und die Zuordnung ist danach dieselbe. Für Java, .NET, Rust und Elixir gibt es gar keinen Agenten. Die Browser-Hälfte funktioniert mit jedem Backend, sieht aber nur, was die Seite selbst anfordert.
OpenTelemetry
OpenTelemetry bereits vorhanden?
Behalte Collector und Exporter. Sixty kann verbundene Traces und nützliche Runtime-Metriken aufnehmen und Release-Regressionen ableiten; native Agents liefern, wo verfügbar, tiefere Funktions- und Treiberdetails.