Performance & Skalierung
Was leistet SpeamCore wo? Diese Seite gibt konkrete Performance-Profile und Skalierungs-Limits.
Performance-Profile (Standard-Mandant)
| Operation | Erwartete Latenz | Last-Limit |
|---|---|---|
| Login + Token-Issue | < 500 ms | 60/min |
| Liste laden (50 Items) | < 800 ms | 60/min User |
| Detail-Page laden | < 1.5 s | 60/min User |
| Stammdaten-Anlage (Kunde, Lieferant) | < 1 s | — |
| Bulk-Import 1000 Datensätze | 30-90 s | 30/h |
| Banking-Sync (FinTS) | 5-30 s | alle 4h |
| Bulk-Mahn-Lauf 100 Posten | 1-3 min | manuell |
| DATEV-Export 10k Buchungen | 30-60 s | manuell |
| PDF-Generierung Beleg | 1-3 s | — |
| KI-Chat-Antwort (einfach) | 2-8 s | — |
| KI-Chat-Antwort (komplex, Tools) | 10-60 s | — |
Skalierung pro Mandant
Sweet-Spot
- Bis 50 MA — keine Performance-Probleme im Standard-Setup
- Bis 5.000 Kunden — Listen + Suche schnell
- Bis 50.000 Belege/Jahr — Buchhaltung performant
- Bis 200 Aufträge/Woche — Disposition flüssig
Stretch-Bereich (Optimierung nötig)
- 50-200 MA — Performance-Tuning sinnvoll, evtl. dedicated Workers
- 5k-50k Kunden — Indexierung prüfen, Filter-Vorlagen
- 50k-500k Belege/Jahr — Cold-Storage für ältere Belege
- 200-500 Aufträge/Woche — Multi-Niederlassung sinnvoll
Limits
- >200 MA pro Mandant — eher mehrere Mandanten / Niederlassungen
- >500k aktive Belege — Archivierung pflicht
- >500 Aufträge/Woche — eigene Disposition-Lösung pro Niederlassung
Skalierung pro Installation (Multi-Mandant)
| Mandanten | Setup-Empfehlung |
|---|---|
| 1-10 | Standard-Cloud-Instanz |
| 10-50 | Dedicated Workers + dedizierte DB |
| 50-200 | Multi-Region + Load-Balancer |
| >200 | Enterprise-Setup, eigene Infrastruktur |
Engpässe — was wo bremst
Datenbank
- Listen-Queries ohne Index auf Custom-Filter-Spalten
- Cross-Modul-Joins (z.B. Kunden + alle Belege + alle Aufträge gleichzeitig)
- Text-Suche auf großen Kommentar-Feldern
Backend (App-Server)
- Bulk-Imports während User-Aktivität — eigene Worker nutzen
- PDF-Generierung parallel — Queue mit max-Konkurrenz
- KI-Chat mit komplexen Tool-Calls — kann CPU intensiv werden
Frontend
- Sehr lange Listen ohne Pagination — Browser-Hang
- Viele Sub-Module-Tabs parallel offen — RAM-Engpass
- Live-Updates (Notifications) bei zu vielen Subscriptions
Netzwerk
- Mobile / Tablet in schwachem Empfang — Tablet-Offline-Modus nutzen
- Großes Dateien hochladen (>50 MB) — Stream-Upload, Resume
Optimierungs-Pattern
Daten-Seite
App-Server-Seite
- Worker-Threads für Bulk-Aktionen
- Queue-System für Async-Tasks
- Cache für Stammdaten (Konten, Steuersätze)
- Load-Balancer bei mehreren Instanzen
Frontend-Seite
- Virtual Scrolling für sehr lange Listen
- Lazy-Loading für Sub-Tabs
- Service-Worker für Offline-Modus
- Bundle-Splitting pro Modul
Monitoring
Standard-Metriken die überwacht werden:
- Response-Zeit pro Endpoint (95th percentile)
- Datenbank-Query-Zeit für Top-10 Queries
- Job-Laufzeiten (Cron)
- Cache-Hit-Rate
- Active-User-Anzahl
- Mandanten-Last-Verteilung
Bei Auffälligkeiten: Alarm an Admin / IT.
Performance-Test pro Welle
Vor großen Releases:
- Load-Test mit 2x normaler Last
- Stress-Test bis Bruchpunkt
- Endurance-Test über 24h
- Spike-Test plötzliche Last-Spitze
KI-Chat-Anwendungen
Welche API-Endpoints haben in den letzten 24h die längsten Response-
Zeiten? Mit Anzahl Calls und 95th-Percentile.
Welche Cron-Jobs laufen am längsten? Mit durchschnittlicher Laufzeit
und Trend gegenüber letztem Monat.
Best-Practices für Sachbearbeiter
- Filter setzen vor langen Listen
- Pagination klein halten
- Browser-Cache leeren bei Performance-Problemen
- Bulk-Aktionen statt Klick-für-Klick
- Background-Jobs außerhalb User-Stoßzeiten