Piyush-Nagar/coding-agents-skills

Leistung ist ein Feature. Entwickle für das 99. Perzentil, nicht für den Durchschnitt. Miss, bevor du optimierst – Intuition liegt fast immer falsch, wenn es darum geht, wo die Zeit bleibt.

Was ist coding-agents-skills?

Diese Skill-Anleitung konzentriert sich auf Leistungsoptimierung in der Softwareentwicklung und bietet eine Reihe von Regeln zur Vermeidung häufiger Performance-Fallstricke. Sie betont den datengesteuerten Ansatz: Vor jeder Optimierung sollte gemessen werden (z.B. mit Flame Graphs, APM-Traces oder EXPLAIN ANALYZE). Die Regeln behandeln typische Probleme wie N+1-Abfragen, unbegrenzte Listenergebnisse, übermäßige Indizierung und das Abrufen unnötiger Spalten (`SELECT *`). Darüber hinaus werden wichtige Praktiken wie Caching mit klarer Invalidierungsstrategie, das Batching von ausgehenden Aufrufen, parallele Verarbeitung anstelle synchroner Remote-Ketten und das Komprimieren von Payloads empfohlen. Die Anleitung ist für Entwickler und KI-Agenten gedacht, die in Backend-Diensten, APIs oder datenbankgestützten Anwendungen arbeiten, und ist plattformunabhängig (gilt für REST, gRPC, relationale Datenbanken usw.). Sie hilft, die Systemleistung zuverlässig und vorhersagbar zu gestalten, anstatt sich auf Bauchgefühl oder Durchschnittswerte zu verlassen.

Funktioniert mit~Claude Code~Codex CLI✓Cursor

npx skills add https://github.com/Piyush-Nagar/coding-agents-skills/tree/HEAD/backend/core/nfr/performance

Dokumentation

Leistung

Leistung ist ein Feature. Entwickle für das 99. Perzentil, nicht für den Durchschnitt. Miss, bevor du optimierst – Intuition liegt fast immer falsch, wenn es darum geht, wo die Zeit bleibt.

Regeln

Profilieren vor dem Optimieren. Raten, wo der heiße Pfad liegt, kostet Tage. Verwende zuerst Flame Graphs, APM-Traces oder EXPLAIN ANALYZE.
Töte N+1-Abfragen. Die mit Abstand größte Latenzquelle in Servicecode. Bevorzuge Joins, Batch-Abrufe oder IN (...) anstelle von Lookups pro Zeile.
Paginiere jeden Listenendpunkt. Unbegrenzte Ergebnismengen führen irgendwann zum Speicherüberlauf eines Pods oder zur Sättigung der Datenbank. Standardmäßig cursor-basierte Paginierung für große Tabellen verwenden.
Indiziere auf Abfrageprädikaten, nicht auf jeder Spalte. Jeder zusätzliche Index verlangsamt Schreibvorgänge und bläht den Speicherplatz auf. Füge einen Index nur hinzu, wenn eine bekannte Abfrage ihn benötigt.
Projiziere nur die benötigten Spalten. SELECT * in ein breites DTO verschwendet Netzwerk, Speicher und Garbage Collection. Gib schmale Projektionen für Listen-APIs zurück.
Cache leseintensive, idempotente Daten. Aber entscheide die Invalidierungsstrategie bevor du den Cache hinzufügst – ein Cache ohne Räumungsplan ist eine Fehlerfabrik.
Setze Verbindungs- und Thread-Pool-Größen explizit. Standardwerte passen selten zu deiner Arbeitslast. Dimensioniere sie basierend auf der downstream-Kapazität, nicht hoch.
Batch ausgehende Aufrufe. Eine Anfrage mit 100 Elementen schlägt 100 Anfragen mit einem Element in jeder Hinsicht – Latenz, CPU, Datenbankverbindungen.
Vermeide synchrone Ketten von Remote-Aufrufen. Latenz summiert sich. Verarbeite parallel oder verschiebe die Arbeit asynchron.
Halte Payloads klein. Komprimiere Antworten, trimme ungenutzte Felder, verwende binäre Protokolle, wo es wichtig ist (gRPC, Protobuf).

Warnsignale

Schleifen, die die Datenbank abfragen.
APIs, die "alle Datensätze" zurückgeben.
Caches ohne TTL und ohne Invalidierung.
Thread-Pool / Verbindungspool auf Framework-Standard in Produktion gesetzt.
Latenz-Dashboards, die nur Durchschnittswerte anzeigen (kein P95/P99).