Skip to content

Sizing und Anforderungen

Diese Seite ist Betriebsleitlinie auf Basis der aktuellen Architektur. Sie ist keine harte Produktgrenzen-Matrix.

Was Last im System treibt

Die wichtigsten Lastmultiplikatoren sind:

  • Anzahl aktiver Tenants
  • Polling-Frequenz fuer Messages, Payloads, Packages und Artifacts
  • Umfang historischer Backfills
  • Payload-Download-Tiefe
  • Archive-Frequenz und Retention
  • Anzahl gleichzeitiger User
  • Anzahl aktiver Celery-Worker-Prozesse
  • ob PostgreSQL und Redis intern oder extern betrieben werden

Eingebaute Intervall-Defaults

Aktuelle Plattform-Metrik-Defaults:

  • Host-Metriken alle 600 Sekunden
  • Django-Metriken alle 300 Sekunden
  • Storage-Quick-Snapshots alle 3600 Sekunden
  • Storage-Deep-Snapshots alle 21600 Sekunden

Aktuelles Dispatch-Limit fuer geplante Reports:

  • 50 Jobs pro Periodic-Pass

Kleine Installation

Sinnvoll fuer:

  • 1 bis 5 User
  • niedriges bis moderates Alert-Volumen
  • wenige Tenants
  • begrenzte Payload- und Archive-Tiefe

Empfohlenes Setup:

  • SQLite kann akzeptabel sein
  • interner Redis kann akzeptabel sein
  • Worker-Profil safe oder balanced

Startleitlinie Infrastruktur:

  • CPU: 2 vCPU
  • RAM: 4 GB
  • Disk: 20 bis 50 GB
  • Storage: persistenter Mount fuer /app/data

Betriebshinweise:

  • Polling konservativ halten
  • schwere Cold-Backfills nicht in Peak-Zeiten fahren
  • akzeptieren, dass interner Redis keine Persistenz hat

Mittlere Installation

Sinnvoll fuer:

  • mehrere Admins
  • regelmaessige Background-Verarbeitung
  • hoeheres Message-Volumen
  • relevante Archive- und Payload-Nutzung

Empfohlenes Setup:

  • PostgreSQL empfohlen
  • externer Redis empfohlen
  • Worker-Profil balanced

Startleitlinie Infrastruktur:

  • CPU: 4 vCPU
  • RAM: 8 bis 16 GB
  • Disk: 100 GB aufwaerts, je nach Archiv-Retention
  • Netzwerk: stabiler, latenzarmer Pfad zu Redis und PostgreSQL

Betriebshinweise:

  • Queue-Monitoring wird Pflicht
  • Table-Growth-Review gehoert in die Regelbetriebsroutine
  • Archive sollten auf gemountetem oder gemanagtem persistentem Storage liegen

Grosse Installation

Sinnvoll fuer:

  • viele Tenants
  • konstante CPI-Ingestion
  • schwerere Payload-Inspektion
  • breites operatives Reporting

Empfohlenes Setup:

  • dediziertes oder gemanagtes PostgreSQL
  • dedizierter oder gemanagter Redis
  • Worker-Profil fast oder custom nur nach evidenzbasiertem Tuning

Startleitlinie Infrastruktur:

  • CPU: 8 vCPU oder mehr
  • RAM: 16 bis 32 GB oder mehr
  • Disk: primaer nach DB-Wachstum und Archiv-Retention dimensionieren
  • Storage: starke IOPS sind wichtiger als nur Rohkapazitaet

Betriebshinweise:

  • Queue-Tiefen kontinuierlich beobachten
  • DB-Write-Latenz und Vacuum-Verhalten verfolgen
  • getrennte Infrastruktur-Services sind stark zu bevorzugen

CPU-Aspekte

CPU-Bedarf steigt durch:

  • viele Celery-Worker
  • Archive-Export und Komprimierung
  • PDF-Export
  • AI-Task-Ausfuehrung
  • Message-Parsing und Batch-Processing

Das Container-Image bringt ausserdem Chromium, Java, PostgreSQL, Redis, Nginx und Python-Runtime mit und ist deshalb kein schlankes Single-Process-Image.

RAM-Aspekte

Der Idle-Footprint wird beeinflusst durch:

  • Gunicorn mit 4 Workern und 2 Threads
  • viele Celery-Worker-Prozesse
  • internes PostgreSQL
  • internen Redis
  • Python-Prozessduplikation ueber mehrere Worker-Gruppen

Bei knappen Ressourcen sind die ersten sicheren Hebel:

  • Celery-Concurrency reduzieren
  • externes PostgreSQL nutzen
  • externen Redis nutzen
  • Archive und Cold-Backfills moderat halten

Disk- und IOPS-Aspekte

Disk-Bedarf wird bestimmt durch:

  • SQLite-Write-Amplification bei SQLite-Betrieb
  • PostgreSQL-Tabellen- und Indexwachstum
  • Archive-Exporte
  • Job- und Service-Logs
  • Payload- und Attachment-Retention

IOPS werden wichtig, wenn:

  • viele Worker gleichzeitig schreiben
  • Archive-Cleanup schwere DB-Wartung anstoesst
  • Storage-Snapshots waehrend aktiver Ingestion laufen

Netzwerk-Aspekte

Netzwerkqualitaet ist relevant fuer:

  • PostgreSQL-Roundtrips
  • Redis-Roundtrips
  • CPI-API-Calls
  • E-Mail-Delivery
  • gemanagte AI-Backends

Wenn Redis oder PostgreSQL remote sind, verbessert niedrige Latenz den Queue-Durchsatz und das Lock-Verhalten.

Praktische Tuning-Reihenfolge

Wenn der Durchsatz nicht reicht, ist die sicherste Reihenfolge:

  1. Queue-Tiefe und Redis-Health validieren
  2. DB-Latenz und Write-Druck validieren
  3. Polling-Frequenzen und Cold-Backfill-Verhalten pruefen
  4. erst dann Worker-Concurrency erhoehen

Diese Reihenfolge passt zu den tatsaechlichen Flaschenhaelsen der aktuellen Architektur.