Ein Zuschauer erzeugt rund zwanzig Anfragen je Sekunde. Bisher baute der
Proxy dafür jedes Mal eine neue Verbindung auf, holte die Antwort komplett
in den Speicher und schickte sie durch gzip — obwohl Videosegmente bereits
komprimiert sind. Gemessen: 47-67 % CPU für einen einzigen Zuschauer.
Jetzt ein gemeinsamer Client mit offenen Verbindungen, die Daten fließen
stückweise durch, und /stream bleibt von der Kompression verschont. Dazu
protokolliert die App die Stream-Anfragen nicht mehr einzeln; das waren
410 Zeilen je Minute bei einem Zuschauer.
Ergebnis: 11,5 % statt 47-67 %. Mit fünfzehn Zuschauern liegt die Last bei
150 % von 400 % verfügbarer Rechenzeit.
Dazu am Rand:
- hlsAlwaysRemux hält den Muxer durchgehend offen. Vorher riss er 60 s nach
dem letzten Zuschauer ab und setzte beim Neuaufbau die Zeitbasis zurück.
- hlsAllowOrigin ist veraltet und heißt jetzt hlsAllowOrigins.
- Der Player holt höchstens mit 1,1-fachem Tempo auf statt mit 1,5. Das
reicht für normale Schwankungen und bleibt unhörbar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013XVnRop5c3or3B8xE2hpgZ
af66ae6e1c