Digitale Mitgliederversammlungen wirken technisch zunächst unkompliziert. OpenSlides installieren, Videokonferenz anbinden, Teilnehmer einladen. In der Praxis zeigt sich schnell, dass die eigentliche Herausforderung nicht die Installation ist, sondern die stabile Skalierung unter realen Bedingungen. Dieser Beitrag beschreibt unsere Erfahrungen aus einer Jahreshauptversammlung mit rund 30 Teilnehmern, die Ursachen für Performanceprobleme und den anschließenden Neuaufbau auf einem frischen vServer.
Ausgangssituation
Die ursprüngliche Umgebung bestand aus:
- OpenSlides in Docker auf einem kleinen vServer
- 4 vCPU
- 1 GB RAM
- externe Videokonferenz über Jitsi
- gleichzeitige Nutzung von Teilnehmerlisten, Abstimmungen und Präsentationsmodus
Die Annahme war einfach: 30 Teilnehmer sind technisch keine große Last. Diese Annahme war falsch.
Was tatsächlich passiert ist
Während der Versammlung traten mehrere Probleme gleichzeitig auf:
- Teilnehmer konnten sich zeitweise nicht einloggen
- Seiten reagierten verzögert
- Abstimmungen wurden verspätet angezeigt
- einzelne Browser verloren die Verbindung
Das Problem lag nicht an der Videokonferenz. Jitsi lief extern und stabil. Die Last entstand innerhalb von OpenSlides selbst.
OpenSlides besteht intern aus mehreren Services:
- Backend Services
- Datastore Reader und Writer
- Redis Message Bus
- PostgreSQL Datenbank
- Proxy und Client
Bei vielen gleichzeitigen Aktionen entstehen sehr viele kleine Datenbankzugriffe und Events. Gerade Abstimmungen erzeugen kurze Lastspitzen.
1 GB RAM reicht dafür schlicht nicht aus. Der Server beginnt zu swappen, Prozesse warten auf I/O und das System fühlt sich instabil an.
Typische Fehleinschätzung
Die häufigste falsche Annahme lautet:
Wenig Teilnehmer gleich wenig Last.
Tatsächlich ist entscheidend:
- wie viele gleichzeitig klicken
- wie oft Abstimmungen gestartet werden
- wie viele Clients parallel aktualisieren
- ob Präsentationsmodus aktiv ist
30 aktive Teilnehmer erzeugen mehr Last als 200 passive Zuschauer.
Analyse nach der Veranstaltung
Die wichtigsten Erkenntnisse:
- RAM war der limitierende Faktor
- Container starteten korrekt, hatten aber keine Reserven
- kurze Lastspitzen führten zu Verzögerungen
- Monitoring fehlte während der Veranstaltung
Die Installation selbst war nicht falsch. Sie war nur zu knapp dimensioniert.
Entscheidung für den Neuaufbau
Statt die bestehende Installation weiter anzupassen wurde bewusst neu gestartet:
Ziele:
- reproduzierbarer Aufbau
- saubere Trennung von Daten und Konfiguration
- ausreichend Reserven für Lastspitzen
- einfache Migration für zukünftige Veranstaltungen
Neue Zielkonfiguration:
- 4 vCPU
- 8 GB RAM
- Docker Compose Standardsetup von OpenSlides
- externer Reverse Proxy mit TLS
- Videokonferenz weiterhin getrennt betrieben
Der Unterschied in der Stabilität war sofort spürbar.
Warum ein frischer Server sinnvoll war
Bei produktiven Veranstaltungen zählt Vorhersagbarkeit mehr als Optimierung.
Ein neuer Server bedeutet:
- keine Altlasten
- keine versteckten Konfigurationsreste
- klare Versionsbasis
- schnelleres Troubleshooting
Gerade im Vereinsumfeld, wo Veranstaltungen selten stattfinden, ist Einfachheit wichtiger als maximale Effizienz.
Lessons Learned
- OpenSlides ist keine einfache Web-App, sondern ein verteiltes System.
- RAM ist wichtiger als CPU.
- Abstimmungen erzeugen Lastspitzen.
- Videokonferenz und OpenSlides sollten getrennt laufen.
- Vor jeder Veranstaltung einen Lasttest durchführen.
Empfehlung für Vereine bis etwa 50 Teilnehmer
Bewährte Mindestgröße:
- 4 vCPU
- 6 bis 8 GB RAM
- SSD Storage
- externe Videokonferenzlösung
Damit bleiben ausreichend Reserven vorhanden, auch wenn viele Teilnehmer gleichzeitig aktiv werden.
Im nächsten Artikel geht es um die konkrete Neuinstallation auf einem frischen vServer inklusive Docker Setup, Migration der Datenbank und typischen Fehlern beim ersten Start.
Schreibe einen Kommentar