Lars/shinkan-jinkendo
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases 3 Wiki Activity
4b2848c7c3
shinkan-jinkendo/docs/architecture/BASELINE_SNAPSHOT.md
Lars 4b2848c7c3
All checks were successful
Deploy Development / deploy (push) Successful in 41s
Details
Test Suite / pytest-backend (push) Successful in 35s
Details
Test Suite / lint-backend (push) Successful in 0s
Details
Test Suite / build-frontend (push) Successful in 11s
Details
Test Suite / playwright-tests (push) Successful in 57s
Details
feat(docs): add performance baseline documentation and update architecture references 
- Introduced a new section for the Performance-Baseline in CLAUDE.md and updated HANDOVER.md to include references to the new BASELINE_SNAPSHOT.md.
- Enhanced architecture documentation in README.md to clarify the purpose of the baseline snapshot and its relevance to the refactor roadmap.
- Refactored OrgInboxContext to implement a unified loading logic for join requests and content reports, improving code maintainability and performance.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-14 06:53:37 +02:00

4.5 KiB
Raw Blame History

Phase 0 – Performance-Baseline (Shinkan Jinkendo)

Zweck: Reproduzierbarer Startpunkt vor Phase 2 (Backend-Lesepfade, Summary-API).
Stand: 2026-05-13 · Backend-App-Version laut backend/version.py: 0.8.110

Nach grösseren Deployments oder Schema-Änderungen: Bundle-Abschnitt neu erfassen (npm run build); API-/k6-Werte bei Bedarf aktualisieren.

1. Frontend-Bundle (npm run build)

Messung: Repo-Root → cd frontend && npm run build (Vite Production).
Hinweis: Dateinamen mit Hash (index-*.js) ändern sich pro Build; relevant sind Grössenordnungen und gzip.

1.1 Einstieg & globale Vendor-Chunks (Auszug letzter Lauf CI-lokal)

Asset (Muster) raw kB gzip kB Rolle
index.html 1.84 0.73 Einstieg
index-*.css 127.55 21.58 Globale Styles
index-*.js (App-Shell / Router) 64.83 17.45 Haupteinstieg nach Code-Splitting
vendor-react-*.js 142.42 45.67 React + DOM
vendor-router-*.js 65.94 22.51 react-router
vendor-markdown-*.js 161.54 49.31 Markdown-Stack (wird mit Routen geladen)
vendor-pdf-*.js 390.80 128.98 jsPDF (Route-bezogen)

1.2 Schwerste Route-Chunks (lazy, nach Route)

Bereich typ. Chunk-Grösse (raw / gzip) Datei-Muster (Beispiel)
Trainingsplanung 71.81 kB / 18.67 kB TrainingPlanningPage-*.js
Übung bearbeiten 91.31 kB / 22.49 kB ExerciseFormPage-*.js
Medienbibliothek 59.42 kB / 13.69 kB MediaLibraryPage-*.js
Dashboard 19.97 kB / 5.93 kB Dashboard-*.js

Abnahme Phase 0 (Bundle): Zahlen dokumentiert; Re-Run: npm run build und Tabelle abgleichen.

2. API-Latenz (p95) – Top-Routen

Messung erfolgt auf Zielumgebung (z. B. dev.shinkan / prod) mit gleicher Topologie wie Nutzer (HTTPS, Proxy). Nicht aus dem leeren Arbeitsverzeichnis ohne laufendes Backend messbar.

2.1 Vorgehen (empfohlen)

  • Access-Logs des Reverse-Proxy (Request-Zeit), oder
  • APM / OpenTelemetry, oder
  • k6 mit authentifizierten Szenarien (Token aus Testaccount; Header X-Auth-Token, ggf. X-Active-Club-Id), oder
  • manuell: wiederholte curl -w '%{time_total}\n' mit gleichem Token

2.2 Vorlage (aus Umgebung ausfüllen)

Route (Beispiel) Methode p95 (ms) Datum / Umgebung Bemerkung
/api/profiles/me GET — nach Messung
/api/exercises (Liste, typ. Query) GET — nach Messung
/api/training-units (Liste, typ. Query) GET — nach Messung
/api/media-assets (Liste) GET — nach Messung
/health GET — nach Messung k6: siehe scripts/load/

Abnahme Phase 0 (API): Verfahren steht; Tabelle mindestens für /health nach erstem k6-Lauf befüllbar; übrige Zeilen bei nächstem Monitoring-Export.

3. Lasttestszenario

3.1 E2E-Smoke (fachlicher Pfad)

  • Befehl: Repository-Root, npm run test:e2e (setzt PLAYWRIGHT_BASE_URL, Testuser per Env, siehe .gitea/workflows/test.yml).
  • Abdeckung: Login, Dashboard, Navigation u. a. – entspricht grob „Login → Dashboard → weitere Screens“.
  • Baseline notieren: Dauer eines vollen Laufs, Anzahl passed (z. B. 26 Tests), Datum.
Messung Wert Datum
Playwright Gesamtlauf (lokal/CI) — nach Messung
passed / total 26 / 26 (Ziel)

3.2 k6 – parallele /health

  • Skript: scripts/load/k6-health-baseline.js
  • Anleitung: scripts/load/README.md
  • Baseline notieren: k6-Ausgabe http_req_duration p(95), Checks succeeded.
Szenario p95 / Fehlerquote Datum / BASE_URL
10 VUs, 30 s /health — nach Messung

4. Nächster Schritt (Roadmap)

  • Phase 0 gilt als abgeschlossen, sobald Bundle-Abschnitt aktuell ist und mindestens ein messbarer Proxy-/k6-Wert für /health (bzw. erste API-Zeile) eingetragen ist – Rest der Tabelle kann iterativ gefüllt werden.
  • Phase 2 (Backend Lesepfade, ggf. Dashboard-Summary) startet erst nach diesem Dokument als verbindlicher Baseline-Einstieg (kein blocker für Code, aber Vergleich nach Phase 2 gegen diese Werte).

Verweise