Performance Tipps
Stream-Performance + Chatlix-Last optimieren.

OBS-Performance
OBS-Performance 
 Chatlix-Overlays laufen als Browser-Sources in OBS. Eine schlecht eingerichtete Browser-Source kann mehr CPU fressen als der eigentliche Stream-Encode. Diese Seite sammelt Tipps, die in der Praxis viel bringen — geordnet vom größten Hebel nach unten. 
 1. Overlays bündeln statt zerfasern 
 Der wichtigste Tipp: Jede Browser-Source in OBS startet eine eigene Chromium-Instanz mit eigenem GPU-Context. Wenn du fünf einzelne Browser-Sources hast (Alerts, Chat, Goal, Persona, Mini-Game) zahlst du fünf Mal den Fixkosten-Overhead. 
 Chatlix erlaubt dir, mehrere Overlay-Module in einer Overlay-Szene zu bündeln. Im Workspace-V2-Editor stapelst du sie übereinander, positionierst sie auf der Stream-Fläche, und gibst OBS am Ende eine einzige URL. Faustregel: so wenig Browser-Sources wie möglich, so viele Module pro Browser-Source wie nötig . 
 In der Praxis macht das bei vielen Setups 20–40% weniger OBS-CPU-Last. 
 2. Auflösung und FPS realistisch wählen 
 Browser-Source-Eigenschaften: 
 
 Breite/Höhe: 1920×1080 ist für Vollbild-Overlays Standard. Wenn dein Overlay nur in einer Ecke sitzt, mach die Browser-Source kleiner (z.B. 600×400) und positioniere sie als Layer. Spart Pixel-Rasterung. 
 FPS: OBS rendert mit Stream-FPS (in der Regel 60). Die Browser-Source liefert intern mit eigener FPS, Default 30. Mehr als 30 für animierte Alerts wirkt nicht viel besser, kostet aber mess­bar CPU. 
 
 3. Hardware-Acceleration testen 
 In OBS unter Einstellungen → Erweitert gibt es "Browser-Source-Hardware-Acceleration aktivieren" . Effekt ist GPU-abhängig: 
 
 NVIDIA mit aktuellem Treiber + NVENC-Encode: meist Gewinn, weil GPU sowieso aktiv ist. 
 AMD / Intel iGPU: kann Gewinn oder Verlust sein — testen mit einem Stream-Probelauf und Task-Manager-Vergleich. 
 Mehrere GPUs (z.B. iGPU + dGPU): prüfen, dass OBS und Browser-Source auf dieselbe GPU laufen, sonst Bus-Kopier-Kosten. 
 
 4. "Shutdown when not visible" ausmachen 
 In den Browser-Source-Eigenschaften gibt es das Häkchen « Quelle herunterfahren, wenn nicht sichtbar » . Klingt nach Sparen, ist aber bei Chatlix oft kontraproduktiv: 
 
 Jeder Szenen-Wechsel feuert ein Shutdown + Reload. 
 Reload heißt: WebSocket zu ws.chatlix.app wieder aufbauen, Auth, Queue-Resync. 
 Im schlimmsten Fall verpasst du in den ersten 2–3 Sekunden nach Szenen-Wechsel eintreffende Alerts. 
 
 Empfehlung: aus. Browser-Sources idle haben sehr niedrige Last, das ist's wert. 
 5. FPS-Target an Encoder anpassen 
 
 NVENC (NVIDIA): 60 fps ohne Probleme. 
 x264 (CPU-Encoder), schwächere CPU: auf 30 fps gehen, sowohl im Stream-Output als auch in der Browser-Source. 
 Intel QSV / AMD AMF: je nach Generation; modernere meist OK mit 60. 
 
 6. Den richtigen Code in OBS-Stats sehen 
 Ansicht → Statistiken zeigt: 
 
 CPU-Last gesamt: muss < 80% bleiben, sonst dropped Frames. 
 Frame-Drops Rendering: wenn das wächst, ist OBS selbst zu lahm (GPU/Browser-Source-Problem). 
 Frame-Drops Encoding: Encoder zu langsam (CPU/GPU-Encoder zu schwach für gewählte Auflösung). 
 Frame-Drops Netzwerk: Upload-Probleme — siehe Seite "Netzwerk". 
 
 7. Vorschau und Studio-Modus 
 Die Vorschau in OBS rendert die Szene zusätzlich. Auf schwachen Systemen kann das messbar Last sparen, wenn du sie ausschaltest ( Ansicht → Vorschau (de)aktivieren ). Studio-Modus rendert sogar zwei Vorschau-Flächen, lohnt sich nur wenn du wirklich vorblendest. 
 8. Last-Profiling mit Chatlix 
 Das Chatlix-Overlay enthält im Debug-Modus eine kleine Anzeige mit aktueller Modul-Anzahl und WS-Latenz. Aktivieren über ?debug=1 an die Overlay-URL. So siehst du direkt im Browser-Source-Interact-Fenster, ob Module steckt oder Render-Loops wegfressen. 
 9. Bei Problemen Modul für Modul abklemmen 
 Wenn die OBS-Last explodiert, geh systematisch vor: Overlay duplizieren, eine Kopie mit nur einem Modul, andere mit weniger, vergleichen. Häufiger Übeltäter sind individuelle Custom-CSS-Animationen mit filter: blur() — die sind GPU-teuer.

Connect-Last
Connect-Last 
 Chatlix Connect läuft im Hintergrund auf deinem Stream-PC und hält die Brücke zwischen Chatlix-Cloud, OBS und (optional) deinen Spielen. Diese Seite erklärt, wie viel Ressourcen Connect wirklich verbraucht, welche Stellschrauben es gibt und wie du Spitzen vermeidest. 
 Baseline-Verbrauch 
 Im Idle-Zustand — Connect läuft, ist gepairt, OBS verbunden, keine aktive Game-Watcher-Pipeline: 
 
 RAM: unter 100 MB. 
 CPU: unter 5% auf einem aktuellen Mid-Range-Prozessor. Auf älteren Quad-Cores kann es punktuell höher peaken. 
 Netzwerk: Heartbeat alle 30 s, < 1 KB Payload. 
 
 Das ist die Untergrenze. Wenn dein System auf dem Limit fährt, sind diese 5% trotzdem spürbar — die meisten Spiele tolerieren sie aber problemlos. 
 Was die Last hochzieht 
 1. Game-Watcher 
 Der Game-Watcher pollt aktive Spielzustände (z.B. Minecraft-Server-Status, Spawn-Detection, ARK-Server-Logs, je nach Adapter). Pro aktivem Adapter: 
 
 Polling-Intervall typisch alle 2–10 s. 
 Pro Poll wenige KB Netzwerk, geringfügig CPU für Parsing. 
 Bei vielen aktiven Adaptern parallel summiert sich das. 
 
 Tipp: Game-Watcher pro Spiel nur einschalten, wenn du dieses Spiel auch tatsächlich streamst. Unter /dashboard/game-watcher ist das ein Toggle pro Adapter. Adapter mit Aus -Schalter verbrauchen nichts. 
 2. Event-Spitzen 
 Hohe Event-Raten erhöhen die Last: 
 
 Raid mit 500 Zuschauern → hunderte Follower-Events in Sekunden. 
 Massive Bits-Cheer-Combos. 
 Subgift-Storms. 
 
 Connect ist auf Spitzen ausgelegt und queued intern. Du wirst während eines Raids kurz höhere CPU sehen, das geht aber innerhalb von Sekunden wieder runter. 
 3. Log-Level 
 Der Log-Level steuert, wie viel auf die Platte geschrieben wird: 
 
 info (Default) — produktiv. Geringe IO-Last. 
 debug — sehr ausführlich, kostet IO und macht das Logfile schnell groß. Nur einschalten, wenn du gezielt diagnostizierst. 
 trace — nur für Support-Sessions. Sollte nicht im Normalbetrieb laufen. 
 
 Änderung unter ~/.config/chatlix-connect/config.yml (Linux) bzw. %APPDATA%\Chatlix\Connect\config.yml (Windows), Feld log_level . Connect neustarten. 
 4. OBS-Polling 
 Connect pollt nicht selbst — OBS-WebSocket pushed Events. Aber: wenn die Verbindung instabil ist (siehe Fehler OBS_NOT_REACHABLE ), versucht Connect alle paar Sekunden zu rebinden. Stabile OBS-Konfiguration = stabil niedrige Connect-Last. 
 Diagnose 
 Status-Kommando 
 chatlix-connect status
 
 gibt unter anderem aus: 
 uptime: 4h32m
memory: 86 MB
cpu_30s_avg: 2.1%
events_last_min: 47
ws_latency_ms: 38
active_adapters: 1
 
 Logs 
 
 Linux: ~/.config/chatlix-connect/connect.log 
 Windows: %APPDATA%\Chatlix\Connect\connect.log 
 
 Das Log rotiert bei 10 MB. Wenn du dauerhaft auf debug läufst, wächst es schnell. Bei Speicherproblemen reicht Log-Level zurück auf info . 
 Wenn Connect zu viel zieht 
 
 Game-Watcher-Adapter durchgehen. Welche sind an, welche brauchst du gerade? Unbenutzte aus. 
 Log-Level auf info setzen. 
 OBS-Verbindung stabilisieren (Passwort prüfen, Firewall, OBS-Studio aktuell). 
 Connect neustarten. Linux: systemctl --user restart chatlix-connect . Windows: Tray-Icon → « Connect neu starten » . 
 Versions-Check: Connect updatet sich nicht automatisch — alte Versionen können Memory-Leaks haben, die in späteren Releases gefixt sind. Aktuelle Version unter /dashboard/downloads . 
 
 Auto-Start 
 Connect startet auf Windows standardmäßig mit dem User-Login, auf Linux per systemd-User-Unit chatlix-connect.service . Wenn du Connect nur während Stream-Sessions willst, deaktiviere den Auto-Start und starte ihn manuell vorm Stream. Das spart die Idle-100 MB den Rest des Tages.

Netzwerk
Netzwerk 
 Chatlix lebt von einer stabilen WebSocket-Verbindung zu ws.chatlix.app . Wenn die wackelt, kommen Alerts verzögert, Personas reagieren verspätet, Mini-Games hängen. Diese Seite zeigt, was du an deinem Heimnetzwerk schrauben kannst, damit Stream + Chatlix-Events parallel sauber laufen. 
 Wie Chatlix das Netzwerk nutzt 
 
 Permanenter WebSocket zwischen Connect und ws.chatlix.app — kleine Pakete, Heartbeat alle 30 s. 
 HTTPS-Aufrufe für Action-Calls, Media-Uploads, Plan-Abfragen — burst-haft. 
 OBS-Overlay-Browser-Sources halten eigene WebSockets — pro Overlay einer. 
 Twitch-EventSub läuft serverseitig, du musst dafür kein eigenes Netzwerk-Budget einplanen. 
 
 Das eigentliche Daten-Volumen ist sehr gering (Größenordnung wenige MB pro Stunde). Was zählt, ist Stabilität und Latenz , nicht Bandbreite. 
 Upload-Bandbreite 
 Der Stream selbst ist der größte Bandbreiten-Fresser. Faustregel: 
 
 720p30: ca. 3 Mbit/s 
 720p60: ca. 4.5 Mbit/s 
 1080p30: ca. 4.5 Mbit/s 
 1080p60: ca. 6 Mbit/s 
 1440p / 4K: deutlich mehr 
 
 Plus Headroom für VoIP/Discord, sonstige Hintergrund-Apps, Chatlix selbst. Faustregel: dein verfügbarer Upload sollte mindestens das 1.3-fache deiner Stream-Bitrate sein. Bei 1080p60 → 5–6 Mbit/s netto verfügbar. 
 Test: speedtest.net während OBS gestoppt ist. Den Wert vor Augen halten. 
 Kabelgebunden vs. WLAN 
 Kabel (Ethernet) ist immer die bessere Wahl. Wenn das nicht geht: 
 
 5 GHz statt 2.4 GHz. 2.4 GHz ist überfüllt (Mikrowellen, Nachbar-Router, Bluetooth) und gibt häufig Drop-Spikes. 
 Sichtverbindung zum Access Point. Wände dämpfen, dicke Wände dämpfen viel. 
 Powerline-Adapter sind eine OK-Notlösung, aber empfindlich gegen Stromnetz-Störungen (Staubsauger, Kühlschrank-Kompressor). 
 Mesh-Systeme mit Backhaul-Link funktionieren in der Praxis erstaunlich gut. 
 
 Wenn du dauerhaft WLAN nutzt: regelmäßig Logs prüfen, Heartbeat-Drops sind das erste Zeichen, bevor sichtbar Frames droppen. 
 VPN 
 Empfehlung: VPN während des Streams aus. 
 
 Ein VPN routet allen Traffic über einen Drittserver. Das addiert Latenz (typisch 20–60 ms) — egal ob "Premium-VPN". 
 Einige VPN-Anbieter blocken oder drosseln WebSocket-Verbindungen. 
 Twitch-Stream-Upload über VPN ist generell ungünstig — manche VPNs haben gegen RTMP gefiltert. 
 
 Wenn du VPN aus IP-Schutz-Gründen brauchst, dann wenigstens Split-Tunneling so konfigurieren, dass OBS und Chatlix Connect am VPN vorbei direkt rausgehen. 
 Heartbeat-Drops im Log 
 Unter ~/.config/chatlix-connect/connect.log (Linux) bzw. %APPDATA%\Chatlix\Connect\connect.log (Windows). Suche nach heartbeat_missed oder ws_reconnect . Wenn diese Einträge in regelmäßigen Abständen kommen: 
 
 Alle 30 Sekunden: Connection-Tracking-Problem irgendwo (Router-NAT-Timeout, Firewall). 
 Bei jedem Stream-Drop: klassisches WLAN-Drop-Pattern. 
 In Bursts: ISP-Probleme, oft abends zu Hauptverkehrszeiten. 
 
 Router-Konfiguration 
 
 QoS: falls dein Router QoS unterstützt, OBS-Output und Chatlix-Connect höher priorisieren als Background-Traffic (Updates, Cloud-Sync). 
 NAT-Timeout: manche Router setzen TCP-NAT-Sessions nach 60–120 s ohne Traffic ab. Das tötet die Chatlix-WS-Verbindung. Connect reconnected zwar, aber wenn das jede Minute passiert, ist das spürbar. Workaround: festen TCP-Keepalive im OS aktivieren oder Router-Timeout hochschrauben. 
 MTU: sehr selten ein Thema, aber bei VPN-/PPPoE-Setups gelegentlich. Wenn alles andere langsam ist und Pings funky werden, MTU 1492 oder 1452 testen. 
 
 Diagnose-Kommandos 
 ping -c 20 ws.chatlix.app
traceroute ws.chatlix.app
 
 Ping-Werte sollten stabil sein, kein Packet-Loss. Traceroute zeigt, ob ein Hop zwischendrin Problem macht — die letzten Hops (CDN-Edge) sind selten das Problem, eher die Bridge zum ISP-Backbone. 
 Wann Chatlix-Cloud schuld ist (selten, aber kommt vor) 
 Falls weder dein Netzwerk noch dein Provider Probleme zeigen, prüfe status.chatlix.app . Bei großflächigen Incidents poster wir dort live. In dem Fall ist es kein lokales Problem, sondern bei uns.