Collabora Online bietet mehrere Einstellungen, die ähnlich wie ein „Leerlauf-Timeout“ klingen, aber unterschiedliche Verhaltensweisen steuern. Wenn ein Editor ausgegraut wird oder die Aktualisierung stoppt, während ein Benutzer noch arbeitet, passen Sie die Inaktivitätseinstellung pro Ansicht an. Bleibt ein Dokument geladen, nachdem alle Benutzer die Arbeit beendet haben, passen Sie das Timeout pro Dokument an. Falls der Editor tatsächlich die Verbindung trennt, überprüfen Sie das WebSocket-Timeout des Reverse-Proxys, bevor Sie die Leerlaufrichtlinie von Collabora ändern.
Die aktuelle Collabora Online-Konfigurationsvorlage sieht ein 15-minütiges Timeout pro Ansicht im Leerlauf, ein 5-minütiges Timeout bei Verlassen des Browser-Tabs und ein einstündiges Timeout vor, bevor ein inaktives Dokument entladen wird. Diese Standardwerte können je nach Version und Paket variieren. Überprüfen Sie daher die mit Ihrer installierten Version ausgelieferte Konfiguration, bevor Sie Änderungen vornehmen. Die unten aufgeführten Werte beziehen sich auf die in diesem Leitfaden verwendete Vorlage und stellen keine Garantie für jede CODE- oder Unternehmensbereitstellung dar.
Wählen Sie die Einstellung basierend auf dem gewünschten Verhalten.
| Einstellung | Was es kontrolliert | Verwenden Sie es, wenn | Abtausch |
per_view.idle_timeout_secs | Die Anzeige wird abgedunkelt und Aktualisierungen werden gestoppt, wenn der Benutzer inaktiv ist, selbst wenn der Browsertab aktiv bleibt. Aktueller Standardwert der Vorlage: 900 Sekunden. | Die Menschen benötigen längere Zeiträume zum Lesen, Überprüfen oder Bearbeiten, ohne ständig interagieren zu müssen. | Ein längeres Timeout hält inaktive Ansichten länger aktiv und kann mehr Client- und Serverressourcen beanspruchen. |
per_view.out_of_focus_timeout_secs | Die Aktualisierungen werden ausgeblendet und gestoppt, sobald der Browsertab nicht mehr im Fokus ist. Aktueller Standardwert: 300 Sekunden. | Während der Zusammenarbeit wechseln die Nutzer zwischen dem Dokument und anderen Registerkarten. | Ein längeres Timeout sorgt dafür, dass Hintergrund-Tabs aktualisiert bleiben; mehrere geöffnete Dokumente können mehr Ressourcen verbrauchen. |
per_document.idle_timeout_secs | Ein Dokument, das inaktiv geworden ist, wird entladen. Aktueller Vorlagenstandard: 3.600 Sekunden. | Dokumente bleiben zu lange im Speicher, nachdem ihre Bearbeitungsansichten inaktiviert oder geschlossen wurden. | Ein kürzerer Wert gibt die Dokumentverarbeitung schneller frei, aber ein späteres erneutes Öffnen erfordert möglicherweise ein erneutes Laden des Dokuments. |
per_document.idlesave_duration_secsUndautosave_duration_secs | Wenn geänderte Dokumente nach Inaktivität oder gemäß dem automatischen Speicherplan gespeichert werden. Aktuelle Standardeinstellungen der Vorlage: 30 und 300 Sekunden. | Sie optimieren die Speicherfrequenz oder untersuchen das Speicherverhalten. | Dies sind Speicherintervalle, keine Einstellungen für den Sitzungsablauf. Eine Änderung dieser Intervalle verhindert nicht, dass eine inaktive Ansicht abgedunkelt wird. |
| Reverse-Proxy-WebSocket-Timeout | Wie lange ein Proxy die WebSocket-Verbindung des Browsers offen hält. | Der Editor trennt die Verbindung oder stürzt nach einer vorhersehbaren Zeit ab, insbesondere im Leerlauf. | Für langlebige Verbindungen müssen auf allen Ebenen – Proxy, Load Balancer und Ingress-Layer – einheitliche Grenzwerte eingehalten werden. |
Collabora dokumentiert die Bedeutungen und Standardeinstellungen in seiner aktuellen coolwsd-Konfigurationsvorlage und der zugehörigen Referenz . Ein Timeout pro Ansicht im Leerlauf ist nicht dasselbe wie das Schließen eines Kontos oder der Entzug des Zugriffs: Es blendet die Ansicht aus und stoppt Aktualisierungen. Ein Timeout pro Dokument beendet einen inaktiven Dokumentprozess; es handelt sich nicht um einen Timer, der einen Benutzer während der Bearbeitung beenden sollte.
Empfohlene Ausgangspunkte
- Verhindern Sie, dass die aktiven Tabs der Benutzer zu früh ausgegraut werden: Erhöhen Sie
per_view.idle_timeout_secsdas standardmäßige Intervall auf einen angemessenen Wert, z. B. 1800 Sekunden (30 Minuten). Dies ist ein praktischer Ausgangspunkt, keine allgemeingültige Empfehlung.
- Ermöglichen Sie es Benutzern, zwischen Tabs zu wechseln, ohne dass ein Dokument ungenutzt bleibt: Erhöhen Sie das Limit
per_view.out_of_focus_timeout_secsseparat. Erhöhen Sie es nicht einfach, nur weil Benutzer in einem aktiven Tab inaktiv sind.
- Reduzieren Sie den Speicherverbrauch, nachdem Dokumente nicht mehr verwendet werden: Lassen Sie die Werte pro Ansicht unverändert und erwägen Sie eine Verringerung von
per_document.idle_timeout_secs, nachdem Sie sich vergewissert haben, dass das Dokument tatsächlich inaktiv ist und die Speichereinstellungen in Ordnung sind.
- Beheben Sie eine zeitabhängige Verbindungsunterbrechung: Überprüfen Sie das WebSocket-Timeout des Proxys, Ingress-Servers oder Load Balancers. Das Ändern der Dimm-Einstellung pro Ansicht behebt keine WebSocket-Verbindung, die vom Proxy geschlossen wurde.
- Häufige Speicherstände beibehalten: Lassen Sie die Werte für Leerlauf-Speichern und automatisches Speichern auf ihren aktuellen Einstellungen, es sei denn, Sie haben einen besonderen Grund, sie zu ändern.
Ändern Sie die Einstellungen in coolwsd.xml
Bei einer paketbasierten Installation suchen Sie die aktive coolwsd.xmlDatei, die vom laufenden Dienst verwendet wird. Gängige Speicherorte sind beispielsweise `/usr/local/bin` /etc/coolwsd/coolwsd.xml, die Pfade können jedoch je nach Distribution und älteren Versionen variieren. Gehen Sie nicht davon aus, dass die Bearbeitung einer Beispieldatei oder einer ungenutzten, eingebundenen Kopie den laufenden Dienst ändert.
Sichern Sie die aktive Datei und bearbeiten Sie anschließend nur die relevanten Werte in den vorhandenen <per_view>Abschnitten <per_document>. Dieser Auszug legt beispielsweise ein Timeout von 30 Minuten für inaktive Benutzer, ein Timeout von 15 Minuten für Hintergrundtabs und ein Timeout von zwei Stunden für inaktive Dokumente fest:
<per_view>
<idle_timeout_secs>1800</idle_timeout_secs>
<out_of_focus_timeout_secs>900</out_of_focus_timeout_secs>
</per_view>
<per_document>
<idle_timeout_secs>7200</idle_timeout_secs>
</per_document>
Dies ist ein Auszug, keine vollständige Ersatzkonfiguration. Behalten Sie die Attribute, Kommentare, Verschachtelungen und andere Elemente der mit Ihrer Version ausgelieferten Datei bei; einige Builds benötigen zusätzliche XML-Attribute. Wenn Sie die Abdunklung nur ändern möchten, solange der Tab den Fokus behält, bearbeiten Sie lediglich den Leerlaufwert pro Ansicht. Wenn Sie sowohl die Leerlaufwerte pro Ansicht als auch den Wert für das Entladen des Dokuments gleichzeitig erhöhen, wird es schwieriger festzustellen, welche Einstellung das Problem behoben hat.
Validieren Sie die XML-Datei mit den von Ihrer Bereitstellung unterstützten Konfigurationstools und starten Sie Collabora anschließend neu oder laden Sie es gemäß der Dokumentation des jeweiligen Pakets neu. Überprüfen Sie die Startprotokolle auf Konfigurationsfehler und stellen Sie sicher, dass der laufende Prozess die gewünschte Datei geladen hat. Eine Einstellungsänderung, die im aktiven Prozess nicht vorhanden ist, hat keine Auswirkung.
Legen Sie die gleichen Optionen in Docker oder Kubernetes fest.
Im Docker-Image von Collabora übergeben Administratoren Konfigurationsoptionen üblicherweise mithilfe extra_paramsder --o:Optionssyntax. Der folgende Compose-ähnliche Wert veranschaulicht dasselbe Beispiel:
extra_params=--o:per_view.idle_timeout_secs=1800 --o:per_view.out_of_focus_timeout_secs=900 --o:per_document.idle_timeout_secs=7200
Verwenden Sie diese Option nur, wenn Ihr Image und Ihr Deployment-Chart dies unterstützen extra_params. Bei Kubernetes, Helm oder einer vom Operator verwalteten Installation tragen Sie die Optionen im Feld „Unterstützte Konfiguration“ des Charts oder der benutzerdefinierten Ressource ein, anstatt eine generierte Containerdatei zu bearbeiten. Wenn Sie Umgebungsvariablen in Compose ändern, erstellen oder stellen Sie den Dienst neu bereit, damit die neuen Werte den Container erreichen; ein einfacher Neustart kann die bestehende Containerkonfiguration wiederverwenden.
Setzen Sie dieselbe Option nicht an mehreren Stellen gleichzeitig, beispielsweise in einer eingebundenen XML-Datei und einem Umgebungsparameter, ohne die Prioritätsregeln der jeweiligen Version zu prüfen. Überprüfen Sie nach der erneuten Bereitstellung die Container-Startprotokolle und die aktive Konfiguration. Das Quellcode-Repository des Collabora-Projekts und die versionsspezifische Bereitstellungsdokumentation sind die geeigneten Referenzen, wenn sich Optionsnamen oder das Containerverhalten unterscheiden.
Überprüfen Sie die Timeouts des Reverse-Proxys separat.
Der Editor von Collabora nutzt WebSockets für die kontinuierliche Browserkommunikation. Ein Proxy kann eine ansonsten gültige WebSocket-Verbindung schließen, selbst wenn die Timeout-Werte für Dokument und Ansicht in Collabora deutlich höher eingestellt sind. In diesem Fall sehen Benutzer möglicherweise eine Meldung über eine Verbindungsunterbrechung, eine Aufforderung zum erneuten Verbinden oder einen Editor, der keine Aktualisierungen mehr empfängt, anstatt einer einfachen Abdunklung der Ansicht.
Vergleichen Sie das Lese-/Sende-Timeout des Proxys, etwaige Leerlauf-Timeouts von Ingress- oder Cloud-Loadbalancern und das von Collabora vorgesehene Sitzungsverhalten. Die Timeouts müssen entlang der gesamten Route kompatibel sein. Die Proxy-Konfigurationsanleitung von Collabora enthält Beispiele für die WebSocket-Proxy-Konfiguration und für dauerhafte Verbindungen. Wenden Sie die für Ihren Proxy und Ihre Version relevanten Hinweise an; kopieren Sie keinen alten Nginx-Block einfach blind in einen anderen Proxy oder eine nicht zugehörige Route.
Ein hilfreicher Hinweis ist das Fehlermuster. Wenn Benutzer nur die ausgegraute, inaktive Ansicht sehen per_view, sollten Sie die Protokolle des Proxys und Load Balancers zu diesem Zeitpunkt überprüfen. Wenn ein Dokument erst geschlossen wird, nachdem alle Teilnehmer das Forum verlassen haben, ist das Timeout pro Dokument relevanter.
Teste jeweils einen Timeout.
- Notieren Sie die aktuellen Werte der aktiven Konfiguration und vermerken Sie Ihre Collabora-Version und die Bereitstellungsmethode.
- Öffnen Sie ein Testdokument mit zwei Benutzern oder zwei Browsersitzungen, um sowohl eine aktive als auch eine inaktive Ansicht zu beobachten.
- Ändern Sie nur das Timeout, das dem Problem entspricht. Um beispielsweise das Abdunkeln eines aktiven, aber ruhigen Tabs zu verhindern, passen Sie
per_view.idle_timeout_secsnur den Timeout-Wert an.
- Starten Sie das System mithilfe der unterstützten Methode neu oder stellen Sie es erneut bereit und überprüfen Sie anschließend, ob der neue Wert in der aktiven Konfiguration oder in den Startprotokollen angezeigt wird.
- Warten Sie über den vorherigen Schwellenwert hinaus. Prüfen Sie, ob die Ansicht weiterhin abgedunkelt wird, der zweite Benutzer weiterhin Aktualisierungen erhält und Änderungen weiterhin gespeichert werden.
- Schließen Sie alle Ansichten des Testdokuments und beobachten Sie, ob das inaktive Dokument innerhalb des vorgesehenen Bereichs entladen wird.
- Prüfen Sie die Collabora- und Proxy-Protokolle auf WebSocket-Closure, XML-Parse-Fehler, fehlgeschlagene Speichervorgänge oder unerwartete Prozessbereinigungen.
Testen Sie die Änderung nicht an einem ungespeicherten Produktionsdokument. Stellen Sie sicher, dass geänderte Dateien im Speichersystem gespeichert werden, bevor ein inaktiver Dokumentprozess beendet wird. Tritt das Problem nur bei ungespeicherten Änderungen auf, prüfen Sie die automatische Speicherung und Speicherfehler als separates Problem, anstatt jedes Timeout zu verlängern.
Ausgewogenheit zwischen Komfort, Ressourcennutzung und Zuverlässigkeit
Längere Timeouts pro Ansicht eignen sich für Teams, die Dokumente in Pausen bearbeiten oder mit mehreren Browser-Tabs arbeiten. Kürzere Werte können dazu führen, dass inaktive Ansichten schneller nicht mehr aktualisiert werden, was die Hintergrundaktivität reduzieren kann. Allerdings können sie Leser, die das Dokument noch betrachten, unterbrechen. Das Timeout pro Dokument ist eine separate Ressourcenmanagement-Entscheidung: Durch eine Verlängerung bleiben ungenutzte Dokumente länger geladen, während eine Verkürzung beim erneuten Laden durch einen Benutzer ein erneutes Laden erforderlich machen kann.
Ändern Sie bei den meisten Bereitstellungen nur die geringstmögliche Anzahl an Einstellungen, die erforderlich sind, um das beobachtete Verhalten nachzubilden. Behalten Sie die Speicherintervalle bei, legen Sie ein angemessenes Inaktivitätsfenster pro Ansicht für das Team fest, behalten Sie das Timeout für Hintergrund-Tabs bei und passen Sie die Proxy-WebSocket-Limits nur dann an, wenn Protokolle oder Zeitmessungen auf ein Problem auf der Verbindungsschicht hinweisen. Überprüfen Sie nach Aktualisierungen die Konfigurationsvorlage der installierten Version erneut, da sich Standardwerte und unterstützte Einstellungen ändern können.