Behebung von Verzögerungen bei der gemeinsamen Bearbeitung in ONLYOFFICE auf einem selbstgehosteten Docker-Server

Wenn die gemeinsame Bearbeitung von Dokumenten in ONLYOFFICE auf einem selbst gehosteten Docker-Server langsam erscheint, sollten Sie nicht sofort undokumentierte Editorparameter ändern. Unterteilen Sie das Problem zunächst in drei messbare Bereiche: Serverauslastung, Verhalten des Reverse-Proxys/WebSockets und Fehler auf Speicher- oder Containerebene. Die gemeinsame Bearbeitung basiert auf einer dauerhaften Echtzeitkommunikation. Daher kann sich ein Server, der Dokumente erfolgreich öffnet, dennoch träge anfühlen, wenn mehrere Personen gleichzeitig tippen.

Dieser Leitfaden verwendet durchgehend ein hypothetisches Beispiel : Ein kleines Team nutzt ONLYOFFICE Docs in Docker hinter NGINX. Ein oder zwei Benutzer können problemlos bearbeiten, aber wenn sechs Personen dasselbe Dokument öffnen, werden Cursoraktualisierungen verzögert angezeigt und die Änderungen anderer Benutzer erscheinen erst nach einer spürbaren Pause. Dieses Beispiel dient lediglich der Veranschaulichung und ist kein Benchmark oder Bericht über eine reale Implementierung.

Stand Oktober 2026 ist ONLYOFFICE Docs 9.4 die im offiziellen Changelog aufgeführte Version. Version 9.4 hat außerdem die Architektur der Community Edition geändert, indem die Abhängigkeiten von RabbitMQ und Datenbanken entfernt wurden. Daher sind Empfehlungen für ältere Versionen möglicherweise nicht mehr mit einem aktuellen Container der Community Edition kompatibel. Überprüfen Sie daher immer Ihre installierte Edition und Version, bevor Sie Optimierungshinweise aus einem älteren Forenbeitrag übernehmen.

1. Messen Sie die Verzögerung, bevor Sie irgendetwas ändern.

Im hypothetischen Fall wäre der erste Fehler, wahllos Dienste neu zu starten und darauf zu hoffen, dass die Verzögerung verschwindet. Stattdessen sollte man einen reproduzierbaren Test durchführen. Öffnen Sie dasselbe Dokument in mehreren Browsersitzungen oder Testkonten, nehmen Sie kurze Änderungen vor und notieren Sie, was verzögert reagiert: Tastatureingaben auf dem lokalen Bildschirm, Mausbewegungen auf dem Remote-Server, das Erscheinen des Textes eines anderen Benutzers, der Speicherstatus oder das anfängliche Laden des Dokuments.

Diese Symptome deuten auf verschiedene Engpässe hin. Wenn der Editor im lokalen Browser einfriert, könnte dies an der clientseitigen CPU oder einem sehr komplexen Dokument liegen. Erfolgt die Eingabe lokal sofort, werden Änderungen auf dem Server aber verzögert übertragen, überprüfen Sie den Netzwerkpfad und die WebSocket-Sitzung. Verlangsamt sich jede Aktion, wenn mehrere Dokumente geöffnet werden, prüfen Sie die CPU-, Speicher-, Auslagerungs- und Festplattenauslastung des Servers.

ONLYOFFICE beschreibt seine Docker-Bereitstellung und die grundlegenden Systemvoraussetzungen im offiziellen Docker-Installationsleitfaden . Für Docker Compose verwenden Sie bitte die offiziellen Docker Compose-Anweisungen .

2. Überprüfen Sie die CPU- und Speicherauslastung, während die Benutzer bearbeiten

Führen Sie auf dem Docker-Host Folgendes aus:

docker stats

Beobachten Sie den Dokumentenserver-Container, während die Testgruppe Änderungen vornimmt. Untersuchen Sie außerdem die Hostressourcen mit Tools wie:

free -h
uptime
vmstat 1
df -h

Die offiziellen Docker-Anforderungen von ONLYOFFICE schreiben für die dokumentierten Konfigurationen mindestens 4 GB RAM und mindestens 40 GB freien Festplattenspeicher vor, zuzüglich Swap-Speicher. Die Richtlinien für Unternehmen verdeutlichen zudem, dass die benötigte Kapazität von der Anzahl gleichzeitig aktiver Benutzer sowie von Anzahl, Art und Größe der Dokumente abhängt. Diese Werte sind Richtwerte und keine Garantie dafür, dass 4 GB für jede Arbeitslast eine reibungslose Zusammenarbeit gewährleisten.

In unserem Beispiel docker statszeigt sich, dass der Dokumentenserver-Container wiederholt die meiste verfügbare CPU-Leistung beansprucht, sobald sechs Personen gleichzeitig tippen. Dies ist ein aussagekräftiger Hinweis: Das Hinzufügen von Proxy-Timeouts führt nicht zu mehr CPU-Leistung. Im nächsten Schritt sollte ein zu restriktives Docker-CPU-Limit aufgehoben, der Container auf einen schnelleren Host verschoben oder die gleichzeitige Arbeitslast reduziert werden. Bleibt die CPU-Auslastung hingegen gering, sollten weitere Untersuchungen durchgeführt werden, bevor Hardware angeschafft wird.

Die offizielle Referenz für veröffentlichte Kapazitätsrichtlinien sind die Docker-Systemanforderungen von ONLYOFFICE Docs .

3. Überprüfen Sie den Festplattenspeicher, die Mounts und den Dateicache.

Die Docker-Dokumentation von ONLYOFFICE nennt persistente Speicherorte, unter anderem /var/log/onlyofficefür Protokolle und /var/lib/onlyofficeden Dateicache. Überprüfen Sie das Dateisystem, das diese Pfade unterstützt, und nicht nur das Root-Dateisystem des Hosts.

df -h
docker inspect documentserver --format '{json .Mounts}'

Wenn ein Bind-Mount auf ein langsames Netzwerkdateisystem oder eine überlastete Festplatte verweist, können das Öffnen, Konvertieren und die Cache-Aktivität von Dokumenten die Latenz erhöhen. Ist die Festplatte fast voll, sollte dies behoben werden, bevor Anwendungsoptimierungen vorgenommen werden. Die Linux-Fehlerbehebungsdokumentation von ONLYOFFICE nennt unzureichenden Festplattenspeicher ausdrücklich als mögliche Ursache für Konvertierungsprobleme.

Das Projekt empfiehlt außerdem, relevante Daten außerhalb des Containers zu speichern, wenn Sie persistente Protokolle, Cache-Speicher oder externe Datenbank-/Redis-/RabbitMQ-Dienste benötigen. Siehe die offizielle Docker-Volume-Anleitung .

4. Überprüfen Sie, ob der Reverse-Proxy die Echtzeitverbindung aufrechterhält.

Viele selbstgehostete Installationen nutzen ONLYOFFICE hinter NGINX, Apache, HAProxy oder Traefik. Die offizielle ONLYOFFICE-Proxy-Dokumentation fordert explizit weitergeleitete Header wie ` X-Forwarded-Proto@example.com` und `@example.com` X-Forwarded-Host. Die von ONLYOFFICE mitgelieferte Konfiguration unterstützt außerdem HTTP/1.1 und die Aktualisierung von WebSockets.

Vergleichen Sie bei NGINX Ihre Konfiguration mit dem offiziellen Beispiel von ONLYOFFICE, anstatt einen generischen WebSocket-Codeausschnitt aus einem anderen Produkt einzufügen. Ein typisches Beispiel sieht wie folgt aus:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Forwarded-Host $the_host;
proxy_set_header X-Forwarded-Proto $the_scheme;

Die genauen Umgebungsanweisungen mapund Proxy-Standorte sind wichtig. Verwenden Sie das vollständige Herstellerbeispiel für Ihre Topologie. Die unterstützten Konfigurationen sind in der Dokumentation „Nur Office verwenden“ hinter dem Proxy veröffentlicht .

Angenommen, in dem hypothetischen Team verfügt der Docker-Host über ausreichend CPU und RAM, aber der Browser stellt die Kollaborationsverbindung wiederholt über eine unternehmensweite NGINX-Schicht her. Dies deutet auf den Proxy-Pfad hin, nicht auf die Rechenkapazität des Dokumentenservers.

5. Bestätigen Sie die WebSocket-Sitzung im Browser.

Öffnen Sie die Entwicklertools Ihres Browsers, wählen Sie das Netzwerk-Panel aus, filtern Sie nach WebSocket-Datenverkehr und laden Sie den Editor neu. Ein erfolgreicher WebSocket-Handshake zeigt typischerweise HTTP 101 Switching Protocolsund eine dauerhafte Verbindung an. Betrachten Sie eine länger andauernde „ausstehende“ WebSocket-Verbindung nicht automatisch als Fehler; eine aktive WebSocket-Verbindung sollte erwartungsgemäß geöffnet bleiben.

Entscheidend sind wiederholte Verbindungsabbrüche und -wiederherstellungen, fehlgeschlagene Handshakes, Proxy-Fehler oder lange Pausen, die mit der Verzögerung der Zusammenarbeit korrelieren. Wenn Remote-Bearbeitungen zeitgleich mit der Wiederherstellung der WebSocket-Verbindung verzögert erfolgen, liegt ein konkretes Netzwerkproblem vor, das behoben werden muss.

Prüfen Sie TLS-Terminierung, Proxy-Leerlaufzeitüberschreitungen, Load-Balancer-Regeln, WAF-Richtlinien und alle Zwischeninstanzen, die den WebSocket-Verkehr möglicherweise nicht schützen. Falls mehrere Proxy-Ebenen vorhanden sind, testen Sie jeden einzelnen Hop, anstatt anzunehmen, dass nur die öffentliche NGINX-Instanz beteiligt ist.

6. Überprüfen Sie die erwarteten Container und die editionspezifische Architektur.

Laufen:

docker compose ps
# or
docker ps

Gehen Sie nicht davon aus, dass jede moderne ONLYOFFICE-Installation dieselbe Sammlung von Redis-, PostgreSQL- oder RabbitMQ-Containern verwenden muss. Hier ist die Version entscheidend. ONLYOFFICE gibt an, dass die Open-Source-Community Edition ab Version 9.4 auf eine Ein-Prozess-Architektur vereinfacht und die Abhängigkeiten von RabbitMQ und Datenbanken entfernt wurden. Enterprise-, Developer- und ältere Community-Installationen sowie benutzerdefinierte Compose-Stacks können sich unterscheiden.

Das bedeutet, dass ein Fehlerbehebungsartikel aus dem Jahr 2023, der besagt, dass „RabbitMQ der Flaschenhals sein muss“, für eine aktuelle Community Edition-Instanz irrelevant sein kann. Ermitteln Sie das Image und die Version, die Sie tatsächlich verwenden:

docker inspect documentserver --format '{.Config.Image}'
docker image ls onlyoffice/documentserver

Das offizielle Änderungsprotokoll der ONLYOFFICE-Dokumentation führt Version 9.4.0 mit einem Veröffentlichungsdatum am 20. Mai 2026 auf. Die Ankündigung des Anbieters zur Veröffentlichung von Docs 9.4 erläutert die Architekturänderung der Community Edition.

7. Aktivieren Sie vorübergehend die Debug-Protokollierung und korrelieren Sie diese mit der Verzögerung.

ONLYOFFICE stellt eine dokumentierte Docker-Umgebungsvariable für die Debug-Protokollierung bereit. Um ein kurzes Zeitfenster für die Fehlerbehebung zu schaffen, fügen Sie Folgendes hinzu:

DS_LOG_LEVEL=DEBUG

Erstellen oder starten Sie anschließend den entsprechenden Container entsprechend Ihrer Bereitstellungsmethode neu und verfolgen Sie die Protokolle:

docker logs -f documentserver
# Docker Compose:
docker compose logs -f documentserver

Laut offizieller Dokumentation sind Docker-Logs sowohl /var/log/onlyoffice/documentserverinnerhalb des Containers als auch im entsprechenden, auf dem Host eingebundenen Log-Verzeichnis verfügbar, sofern dieses eingebunden ist. Das Konverter-Log ist hilfreich, wenn das Öffnen oder Konvertieren von Dateien langsam ist. Probleme bei der gemeinsamen Dokumentenerstellung sollten hingegen mit den Document-Server-Logs und Beobachtungen zum Browser- und Netzwerkverhalten korreliert werden.

Deaktivieren Sie den DEBUG-Modus wieder, nachdem Sie die benötigten Daten erfasst haben. Die ausführliche Protokollierung dient der Diagnose und ist keine dauerhafte Leistungseinstellung. Befolgen Sie die Anweisungen des Herstellers unter „ Aktivieren der Debug-Protokollierung in der ONLYOFFICE-Dokumentation“ .

8. Führen Sie ein Update sorgfältig durch, wenn Sie ein altes Image verwenden.

Wenn die Bereitstellung deutlich hinter der unterstützten Versionslinie zurückliegt, kann ein Update Fehlerbehebungen und Architekturverbesserungen enthalten. Die Vorgehensweise „Neueste Version herunterladen und neu starten“ ist jedoch keine sichere Methode, um die Leistung eines produktiven Kollaborationsservers zu gewährleisten.

Notieren Sie zunächst das aktuelle Image-Tag, die Compose-Datei, die JWT-Einstellungen, die eingebundenen Volumes, die Reverse-Proxy-Konfiguration und die Integrationskonfiguration. Verwenden Sie eine festgelegte Version, wenn Ihr Änderungsprozess reproduzierbar sein muss. Die Docker-Installationsanleitung von ONLYOFFICE beschreibt, wie Sie eine bestimmte Version angeben, und das offizielle Änderungsprotokoll informiert Sie über die Änderungen.

Bevor Sie einen stark ausgelasteten Dokumentenserver absichtlich anhalten, befolgen Sie die Anweisungen von ONLYOFFICE zum Herunterfahren für Ihre Edition und Bereitstellung, um eine sichere Verarbeitung aktiver Bearbeitungssitzungen zu gewährleisten. Verwenden Sie für Ihren Upgrade-Test kein Testdokument mit ungespeicherten Benutzerdaten.

Wie der hypothetische Fall die tatsächliche Lösung eingrenzt

Kehren Sie zum Beispielteam mit sechs Mitredakteuren zurück. Das Ergebnis der Fehlersuche hängt von Ihren Beobachtungen ab:

Eine praktische Grundlage für Docker-Bereitstellungen

Für eine kleine, selbstgehostete Installation beginnen Sie mit den veröffentlichten ONLYOFFICE-Mindestanforderungen, dimensionieren Sie die Umgebung jedoch anhand Ihrer tatsächlichen gleichzeitigen Aktivitäten und nicht anhand der Anzahl registrierter Benutzer. Speichern Sie Protokolle und Caches persistent auf einem Speicher mit vorhersehbarer Latenz. Vermeiden Sie enge CPU- oder Speichergrenzen, es sei denn, Sie haben die Arbeitslast gemessen. Verhindern Sie, dass der Docker-Host selbst unter normaler Bearbeitungslast auslagert.

Platzieren Sie ONLYOFFICE hinter einer Reverse-Proxy-Konfiguration, die auf den vom Hersteller bereitgestellten Beispielen basiert. Dabei sollten WebSocket-Upgrades und weitergeleitete Host-/Protokoll-Header erhalten bleiben. Überwachen Sie den Server während der gemeinsamen Bearbeitung, nicht nur im Leerlauf. Falls Sie detailliertere Informationen benötigen, aktivieren Sie vorübergehend die Debug-Protokollierung und korrelieren Sie die Protokoll-Zeitstempel mit dem WebSocket-Verhalten des Browsers und den Host-Metriken.

Was man nicht tun sollte

• Ändern Sie undokumentierte Werte nicht local.jsoneinfach deshalb, weil sie in einem Forenbeitrag als „Leistungsoptimierungen“ bezeichnet werden.
• Gehen Sie nicht davon aus, dass eine persistente WebSocket-Verbindung, die als „ausstehend“ angezeigt wird, defekt ist; langlebige WebSockets sind zu erwarten.
• Fügen Sie Redis, RabbitMQ oder PostgreSQL nicht nur deshalb hinzu, weil sie in einem älteren Bereitstellungsdiagramm verwendet wurden. Überprüfen Sie zuerst die Architektur Ihrer Edition und Version.
• Deaktivieren Sie nicht die TLS-Verifizierung, die JWT-Sicherheit oder den Proxy-Schutz, um die Latenzzeit zu verringern.
• Vergleichen Sie nicht die Leerlauf-Servermetrik mit dem Zeitraum, in dem Benutzer tatsächlich Verzögerungen melden.
• Führen Sie kein Upgrade einer Produktionsinstanz durch, ohne Volumes, Konfiguration und einen Rollback-Pfad zu sichern.

Fazit

Die Verzögerung bei der gemeinsamen Bearbeitung in ONLYOFFICE lässt sich am einfachsten beheben, wenn man sie als messbares Systemproblem behandelt. Reproduzieren Sie die Verzögerung, beobachten Sie die Docker- und Host-Ressourcen unter Last, überprüfen Sie den Speicher, stellen Sie sicher, dass der Browser über jeden Proxy eine stabile WebSocket-Verbindung aufrechterhält, und untersuchen Sie die Protokolle nur für den Zeitraum, in dem die Verzögerung auftritt. Sobald Sie wissen, ob der Flaschenhals Rechenleistung, Arbeitsspeicher, Festplatte, Netzwerk-/Proxy-Verhalten oder eine bestimmte Versions-/Konfigurationsänderung ist, wird die Behebung gezielt statt spekulativ.

Für aktuelle Details zur Bereitstellung nutzen Sie bitte die ONLYOFFICE Docker-Installationsdokumentation , die offiziellen Reverse-Proxy-Beispiele , den Leitfaden zur Debug-Protokollierung und das offizielle Änderungsprotokoll der Dokumentation .