Beheben Sie Verzögerungen beim gemeinsamen Bearbeiten in ONLYOFFICE, indem Sie den Flaschenhals finden.

Wenn die gemeinsame Bearbeitung mit ONLYOFFICE auf einem selbst gehosteten Docker-Server langsam erscheint, ermitteln Sie zunächst, ob die Verzögerung serverseitig, im Netzwerkpfad oder an einem bestimmten Dokument liegt. Messen Sie dieselbe Bearbeitungssitzung, bevor Sie Änderungen vornehmen: Überprüfen Sie die Ressourcennutzung von Container und Host und stellen Sie sicher, dass Ihr Reverse-Proxy die Verbindung des Live-Editors korrekt weiterleitet. Erweitern Sie CPU, Arbeitsspeicher oder Infrastruktur erst dann, wenn diese Messungen eine Kapazitätsgrenze aufzeigen.

1. Reproduzieren Sie die Verzögerung und überprüfen Sie den Server, bevor Sie ihn optimieren.

Bitten Sie zwei Bearbeiter, dasselbe Dokument zu öffnen und gleichzeitig eine kleine Änderung vorzunehmen. Achten Sie darauf, ob die Eingabe bei beiden Benutzern verzögert erfolgt, ob ein Benutzer die Aktualisierungen erst später sieht und ob das Problem bei allen Dateien oder nur bei einer großen oder komplexen Datei auftritt. Dieser einfache Vergleich hilft, ein allgemeines Serviceproblem von einem dokumentspezifischen Problem zu unterscheiden.

Identifizieren Sie auf dem Docker-Host den Document-Server-Container und beobachten Sie dessen Ressourcennutzung, während die Verzögerung auftritt:

docker ps
 docker stats <container_name_or_id>

Achten Sie auf anhaltende CPU-Auslastung, Speicherauslastung nahe der Host- oder Containergrenze, Swap-Aktivität oder einen Container-Neustart. Prüfen Sie außerdem den Host-Festplattenspeicher und die E/A-Last, wenn Speichervorgänge oder das Laden von Dokumenten pausieren. Ein kurzer Anstieg ist weniger aussagekräftig als ein Engpass, der mit den langsamen Bearbeitungen zusammenfällt. Die ONLYOFFICE-Docker-Fehlerbehebungsseite weist darauf hin, dass der Speicherverbrauch mit geöffneten Dokumenten und gleichzeitigen Benutzern steigt; sie gibt 2–4 GB als normal für einen Server mit einigen Dutzend aktiven Benutzern an, dies ist jedoch keine allgemeingültige Dimensionierungsgarantie.

Beachten Sie, dass ONLYOFFICE einen gleichzeitig aktiven Benutzer als jemanden zählt, der ein Dokument geöffnet hat – egal ob zum Bearbeiten oder Anzeigen. Vergleichen Sie Ihre maximale Anzahl geöffneter Dokumente mit den editionsspezifischen Systemanforderungen für Community Docker . Die veröffentlichten Werte sind Referenzkonfigurationen; die Dokumentation weist darauf hin, dass die tatsächliche Kapazität von Dokumenttyp und -größe abhängt.

2. Falls die Redakteure die Verbindung wiederherstellen, überprüfen Sie den Proxy und den Netzwerkpfad.

Wenn der Editor zwar lädt, die Mitbearbeiter aber wiederholt die Verbindung verlieren oder die Verzögerung nur über Ihre öffentliche URL auftritt, überprüfen Sie den Reverse-Proxy, bevor Sie Serverressourcen hinzufügen. WebSocket ist die permanente Verbindung, die für den Live-Datenverkehr des Editors verwendet wird. Ein Proxy, der diese Verbindung schließt oder nicht aktualisiert, kann dazu führen, dass Bearbeitungen verzögert erscheinen oder Verbindungsabbrüche auftreten.

Überprüfen Sie die Zugriffs- und Fehlerprotokolle des Proxys während einer Sitzung mit Verzögerungen. Stellen Sie sicher, dass Ihre Konfiguration die HTTP-Upgrade- und Verbindungsheader weiterleitet und den ursprünglichen Host und das Protokoll beibehält. Vergleichen Sie bei NGINX Ihre Konfiguration mit den offiziellen Proxy-Beispielen von ONLYOFFICE ; die Dokumentation weist explizit auf weitergeleitete Header hin X-Forwarded-Proto. X-Forwarded-HostVerwenden Sie kein Beispiel unverändert, wenn Ihre TLS-Terminierung, Ihr Pfadpräfix oder Ihre Proxy-Topologie abweichen.

Testen Sie die Verbindung auch von einem Client im selben LAN und über die normale Remote-Route. Wenn die LAN-Verbindung schnell reagiert, die öffentliche Route aber langsam ist, untersuchen Sie Proxy, Firewall, VPN, DNS oder WAN-Latenz. Wenn beide Routen gleichzeitig verzögert sind, deutet dies eher auf eine Serverlast hin. Die Entwicklertools des Browsers können hierbei helfen: Wiederholte WebSocket-Verbindungsabbrüche weisen auf Probleme mit der Verbindungsverwaltung hin, während eine stabile Verbindung mit langsamer Bearbeitung auf einem ausgelasteten Host auf Kapazitäts- oder Arbeitslastprobleme hindeutet.

3. Wählen Sie „Schnell“ oder „Streng“ für den Workflow, nicht als Serverlösung.

ONLYOFFICE bietet schnelles gemeinsames Bearbeiten (Standardeinstellung), bei dem die Änderungen anderer Benutzer in Echtzeit angezeigt werden, und strenges gemeinsames Bearbeiten, bei dem Änderungen so lange zurückgehalten werden, bis ein Benutzer sie speichert. Die Dokumentation zum gemeinsamen Bearbeiten beschreibt die Unterschiede in der Darstellung von Änderungen. Strenges Bearbeiten eignet sich für Teams, die Änderungen lieber in Stapeln prüfen und anwenden möchten; schnelles Bearbeiten ist die optimale Wahl, wenn sofortige gemeinsame Sichtbarkeit wichtig ist.

Das Ändern des Betriebsmodus behebt weder eine ausgelastete CPU noch einen begrenzten Arbeitsspeicher oder eine fehlerhafte WebSocket-Verbindung. Betrachten Sie den Betriebsmodus als eine Präferenz für die Zusammenarbeit und vergleichen Sie die Anzahl der Dateien und Benutzer in den verschiedenen Modi nur dann, wenn Ihr Team entscheiden muss, welcher Workflow am besten geeignet ist. Vermeiden Sie es, einen Moduswechsel als garantierte Leistungsverbesserung darzustellen.

4. Skala erst nach der Messung zur Ermittlung des Kapazitätsdrucks

Wenn es bei Dokumenten und Benutzern zu Verzögerungen kommt, während die CPU ausgelastet ist, der Arbeitsspeicher begrenzt ist oder Container neu gestartet werden, stellen Sie dem Dokumentenserver zunächst ausreichende Host-Ressourcen zur Verfügung und prüfen Sie, ob die Docker-Limits die Host-Leistung nicht beeinträchtigen. Testen Sie anschließend erneut. Die veröffentlichte Docker-Referenz der Community Edition gibt 4 GB RAM und je nach Anzahl gleichzeitiger Benutzer unterschiedliche Speicheranforderungen an. Für mehr als 400 gleichzeitig aktive Benutzer wird eine Cluster-Bereitstellung empfohlen, wobei auf Kubernetes verwiesen wird. Nutzen Sie diese Angaben als Planungsgrundlage und nicht als Garantie dafür, dass ein bestimmter Server eine spezifische Arbeitslast bewältigen kann.

Bei kleinen Installationen ist die Erhöhung der verfügbaren CPU- oder Speicherkapazität in der Regel einfacher als die Verteilung von Diensten auf mehrere Hosts. Für dauerhaft hohe Parallelität bieten separate oder geclusterte Dienste zwar mehr Spielraum, bringen aber zusätzliche Netzwerkabhängigkeiten, Konfigurationsaufwand, Überwachung und potenzielle Fehlerquellen mit sich. Das aktuelle offizielle Compose-Beispiel von ONLYOFFICE beinhaltet eine Integritätsprüfung für den Dokumentenserver-Endpunkt. Nutzen Sie die Containerintegrität und die Reaktionsfähigkeit der Anwendung gemeinsam, anstatt anzunehmen, dass ein laufender Container automatisch einen fehlerfreien Bearbeitungspfad bedeutet. Fixieren Sie die Image-Version während der Diagnose, damit ein Deployment-Update die Vorher-Nachher-Messungen nicht verfälscht.

Überprüfen Sie die Korrektur mit demselben Bearbeitungstest.

Wiederholen Sie die ursprüngliche Bearbeitung durch zwei Benutzer mit demselben Dokument, demselben Client-Route und derselben ungefähren Last. Stellen Sie sicher, dass die Eingabe für beide Bearbeiter reaktionsschnell ist, Änderungen im gewählten gemeinsamen Bearbeitungsmodus konsistent angezeigt werden und keine Verbindungsabbrüche oder Container-Neustarts mehr auftreten. Beobachten Sie docker statsden erneuten Test und prüfen Sie die Proxy-Protokolle, falls das Problem verbindungsbedingt war. Wenn ein kleiner Test erfolgreich ist, es aber in Spitzenzeiten weiterhin zu Verzögerungen kommt, erfassen Sie das Container-Image/die Version, die Host- und Docker-Versionen, die eingebundenen Volumes, die Ressourcendiagramme und relevante Protokolle, bevor Sie weitere Einstellungen ändern. Die offizielle Anleitung zur Debug-Protokollierung erklärt, wie temporäre Debug-Protokolle in Docker aktiviert werden. Reduzieren Sie die ausführliche Protokollierung nach der Datenerfassung wieder, da sie das Protokollvolumen erhöht.

Nutzen Sie das Ergebnis, um den richtigen Kompromiss zu finden: Korrigieren Sie den Proxy, wenn Verbindungen abbrechen, erhöhen Sie die Kapazität, wenn Messungen einen anhaltenden Ressourcendruck anzeigen, und lassen Sie den Server in Ruhe, wenn nur ein komplexes Dokument betroffen ist, bis Sie diese Arbeitslast isoliert haben.