till/managarten
1
0
Fork 0
mirror of https://github.com/Memo-2023/mana-monorepo.git synced 2026-05-14 23:01:09 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
managarten/docs/CAPACITY_PLANNING.md
Till JS 851a281e5a refactor: rename zitare -> quotes (Zitate) 
Zitare was opaque Latin/Italian-flavored branding. Renamed to clear
English "quotes" (DE: Zitate) matching short-concrete-noun cluster.

- Module, routes, API, i18n, standalone landing app, plans dirs
- Dexie tables: quotesFavorites, quotesLists, quotesListTags,
  customQuotes (dropped redundant "quotes" prefix on the last)
- Logo QuotesLogo, theme quotes.css, search provider, dashboard
  widget QuoteWidget
- German user-facing label "Zitate" (English brand stays Quotes)

Pre-launch, no data migration needed.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-14 20:59:16 +02:00

6.2 KiB
Raw Blame History

Kapazitaetsplanung & Hardware-Ressourcen

Stand: 2026-03-28

Hardware-Uebersicht

Mac Mini M4 (Produktionsserver)

Ressource Wert
CPU Apple M4, 10 Cores (4P + 6E)
RAM 16 GB Unified Memory
GPU 10-Core Metal (geteilt mit CPU/RAM)
Storage intern 228 GB SSD
Storage extern 4 TB SSD (USB-C, ~1 GB/s)
Netzwerk Cloudflare Tunnel (kein direktes Port-Forwarding)

Windows GPU Server (AI-Workloads)

Ressource Wert
GPU NVIDIA RTX 3090, 24 GB VRAM
Netzwerk LAN (192.168.178.11), Tunnel-Subdomains unter gpu-*.mana.how
Services Ollama (11434), STT (3020), TTS (3022), Image Gen (3023)
Status Aktiv — alle AI-Services vom Mac Mini hierher verlagert

Aktuelle Auslastung (Mac Mini)

Container-Uebersicht (61 Container)

Kategorie Anzahl Geschaetzter RAM
Infrastruktur (Postgres, Redis, MinIO, Forgejo) 7 ~2.5 GB
Core Services (Auth, Credits, User, Subs, Analytics) 5 ~0.8 GB
Go Services (Gateway, Sync, Search, Notify, Crawler, Media) 6 ~0.3 GB
Web Apps (SvelteKit, 19 Apps) 19 ~3.0 GB
Backends (NestJS/Hono) 3 ~0.5 GB
Matrix (Synapse, Element, Bots) 4 ~1.0 GB
Monitoring (Grafana, Victoria, Loki, cAdvisor, etc.) 13 ~2.0 GB
Sonstiges (Watchtower, Landing Builder, LLM) 4 ~0.5 GB
Gesamt 61 ~10.6 GB

Native Services (deaktiviert seit 2026-03-28)

Ollama, FLUX.2 und Telegram Bot wurden auf den GPU-Server migriert. Keine nativen AI-Services mehr auf dem Mac Mini.

RAM-Budget

Verfuegbar:           16.0 GB
Docker Container:    -10.6 GB
macOS Overhead:       -1.5 GB
─────────────────────────────
Frei fuer Builds/Peaks: 3.9 GB  ← stabil, kein Ollama-Konflikt

Keine RAM-Konkurrenz mit LLM-Modellen mehr. Build-Script muss Monitoring-Container nur noch bei grossen Multi-App-Builds stoppen.

Kapazitaetsschaetzung nach Workload-Typ

Tier 1: Statische/Local-First Apps (wenig Server-Last)

Apps wie Todo, Calendar, Clock, Quotes, Contacts, etc.

Metrik Wert Begruendung
Gleichzeitige User 100-200 Local-first: Reads aus IndexedDB, Server nur fuer Sync
Sync-Connections (WebSocket) ~50 aktiv mana-sync (Go) ist sehr effizient, ~10 KB/Connection
Bottleneck Cloudflare Tunnel Latenz (~4s first byte) Nicht die App selbst

Tier 2: API-lastige Apps (Chat, Questions, Context)

Metrik Wert Begruendung
Gleichzeitige User 20-50 Abhaengig von Postgres-Connections (max 20 pro Service)
API Requests/sec ~100-200 NestJS/Hono koennen mehr, DB ist Limit
Bottleneck PostgreSQL Connections + RAM

Tier 3: AI-Workloads (GPU-Server, RTX 3090)

Metrik Wert Begruendung
LLM gleichzeitig 5 OLLAMA_MAX_CONCURRENT=5, 24 GB VRAM
LLM Durchsatz ~80-100 tokens/sec (12B) CUDA deutlich schneller als Metal
Bildgenerierung 3-5 gleichzeitig ~0.5s pro 1024x1024 Bild
Bottleneck VRAM (24 GB) Aber kein Konflikt mit Hosting

Gesamtschaetzung (nach GPU-Offload)

Szenario Max. gleichzeitige User
Nur Local-First Apps ~200
Mixed (Local-First + API) ~100-150
Mit aktiver LLM-Nutzung ~80-120
Peak (alle Services + LLM + Bildgen) ~80-150

Bottleneck-Analyse

Rang Bottleneck Auswirkung Loesung
1 Cloudflare Tunnel Latenz ~4s TTFB fuer erste Requests CDN/Workers fuer statische Assets
2 PostgreSQL Connections Max 20 pro Service, shared DB Connection Pooling (PgBouncer)
3 Single Server Kein Failover, kein horizontales Scaling Zweiter Mac Mini oder Cloud-Burst
4 GPU-Server LAN-Latenz <1ms, vernachlaessigbar Kein Handlungsbedarf

Scaling-Roadmap

Phase 1: Optimierung (0 EUR)

  • GPU-Server ueber LAN anbinden → alle AI-Last vom Mac Mini verlagert
  • Ollama/FLUX.2/Telegram-Bot auf Mac Mini deaktiviert
  • Registrierungslimit implementiert (MAX_DAILY_SIGNUPS, default: unlimitiert)
  • Health-Checks und status.sh auf GPU-Server umgestellt
  • Docker Desktop → Colima migrieren (~10 GB RAM gespart, MIT-Lizenz)
  • PgBouncer fuer Connection Pooling einrichten
  • Cloudflare Cache Rules fuer statische Assets
  • Registrierungslimit aktivieren (5/Tag) in .env auf Server

Phase 2: RAM-Upgrade (~700 EUR)

  • Neuer Mac Mini M4 mit 32 GB → doppelte Kapazitaet
  • Oder: gebrauchter Mac Mini M2 als zweiter Server
  • Registrierungslimit auf 15/Tag erhoehen

Phase 3: Horizontales Scaling (~50 EUR/Monat)

  • Hetzner VPS fuer statische Web-Apps (CAX21: 8 GB, 4 vCPU, ~8 EUR/Monat)
  • Oder: Coolify/Kamal auf dediziertem Server
  • Registrierungslimit auf 50/Tag erhoehen

Phase 4: Production-Grade (~200 EUR/Monat)

  • Managed PostgreSQL (z.B. Supabase, Neon)
  • CDN fuer alle Web-Apps
  • Multi-Server mit Load Balancing
  • Registrierungslimit entfernen oder auf 500/Tag

Registrierungslimit ("Organic Growth Gate")

Siehe Implementierung in services/mana-auth/src/services/signup-limit.ts.

Konzept

Pro Tag koennen sich maximal X neue Nutzer registrieren. Das Limit ist konfigurierbar und waechst mit der Hardware.

Vorteile

  1. Infrastruktur-Schutz: Hardware waechst mit der Community
  2. Exklusivitaet: "Heute noch 2 Plaetze frei" erzeugt Nachfrage
  3. Qualitaet: Fruehe User geben besseres Feedback
  4. Kostenlos: Kein Over-Provisioning noetig

Geplante Limits

Phase Limit Kumuliert/30 Tage Hardware
Start 5/Tag ~150 User Mac Mini 16 GB
Phase 2 15/Tag ~450 User Mac Mini 32 GB
Phase 3 50/Tag ~1500 User Multi-Server

Load Testing

Load Tests liegen in load-tests/. Siehe load-tests/README.md fuer Ausfuehrung.

Empfohlene Test-Zyklen

  1. Vor jedem Hardware-Upgrade: Baseline messen
  2. Nach Limit-Erhoehung: Verifizieren dass Hardware haelt
  3. Monatlich: Regression erkennen