pulse-performance
Performance- und Ressourcenprüfung für Pulse – 768-MiB-Containerbudget (Warnung/Kritisch/Notfall 500/620/700 MB), begrenzte Caches/Queues, blockierende Aufrufe im Event-Loop, teure Dashboard-Seiten, S
SKILL.md.claude/skills/pulse-performance/SKILL.md
GitHubPulse-Performance
Bot und Webserver laufen im selben Prozess und Event-Loop – jede blockierende Arbeit im Dashboard verzögert den Bot und umgekehrt. Nur lokal messen (Preview-Server / TestClient), nie gegen den VPS lasten.
1. Statische Prüfung (Diff oder Bereich)
- Speicher (Regel 7): Jede neue Sammlung, die mit Nutzern/Nachrichten/Zeit wächst, braucht eine Obergrenze (
deque(maxlen=…), LRU, Ablauf). Vorbild: begrenzter Rate-Limiter inwebserver.py(„full state rejects new keys“). Keine vollständigen Member-/Nachrichtenlisten im Speicher halten. - Event-Loop: Keine
time.sleep, synchronen HTTP-Aufrufe, großen Datei-/Zip-/SQLite-Operationen direkt inasync def–asyncio.to_threadnutzen. Discord-Fetches (fetch_*) statt Cache nur wo nötig. - Scheduler: Neue Hintergrundarbeit in vorhandene Loops/
pulse_jobs.tracked(...)einhängen, Tasks überpulse_tasks.spawn(Fehler werden erfasst). Kein neuer Dauer-Loop pro Feature,jitterfür Intervalle. - Discord-Limits: Massenaktionen (Rollen, Nicknames, Nachrichten) gedrosselt, 429/
retry_afterrespektiert, kein endloses Retry. - SQLite/JSON: Keine N+1-Abfragen in Schleifen über Mitglieder; Indizes für neue Filterspalten (Migration in
pulse_migrations); große JSON-Dateien nicht pro Request mehrfach laden. 5a. Polling/Netzwerk: Keine engen Polling-Schleifen (Dashboard-JS oder Bot); externe Aufrufe mit Timeout, Backoff und Ausfall-Fallback, kein Abruf pro Request, wenn ein Cache mit TTL reicht. - Dashboard-Seiten: HTML-Aufbau in Schleifen ohne wiederholte teure Lookups (
guild.get_membervorab sammeln); Paginierung/Limit für Listen (Audit-Log, Tickets, Transkripte).
2. Messen (bei Bedarf)
- Gleichwertigkeit + Laufzeit: Muster aus
tests/test_performance.py(Phase-3-Optimierungen müssen identische Ergebnisse liefern). - Seitenzeit lokal: Preview-Server (
tools/preview_server.py) starten und mithttpxmehrfach abrufen (Median/p95), odercProfileum den Handler mit TestClient. - Speicher:
tracemallocvor/nach N simulierten Ereignissen; Wachstum muss bei Obergrenze stagnieren. Produktionswert liefert/healthz(memory_mbviapulse_ultimate.container_memory_mb) – nur lesen.
3. Ergebnis (Deutsch)
Befunde mit datei:zeile, erwarteter Wirkung (z. B. „wächst pro Nachricht um ~1 KB ohne Grenze“), Messwerten vorher/nachher falls gemessen, und Test, der Obergrenze bzw. Ergebnisgleichheit absichert. Nichts als „schneller“ melden, was nicht gemessen wurde; Messwerte und Schätzungen getrennt ausweisen. Vorhandene Werkzeuge (tracemalloc, cProfile, tests/test_performance.py) vor neuen Abhängigkeiten nutzen; keine kostenpflichtige KI-API einführen.