Collabora Online vs. ONLYOFFICE: Ressourcennutzungs- und Latenztest

Die Wahl zwischen Collabora Online und ONLYOFFICE Docs wird oft als Frage nach Funktionen oder Dateiformaten dargestellt. Infrastrukturteams stoßen jedoch nach der Implementierung meist auf eine zweite Herausforderung: Wie viel CPU und Arbeitsspeicher benötigt die jeweilige Lösung, und wie reaktionsschnell bleibt die Bearbeitung bei steigender Roundtrip-Zeit und zunehmender Anzahl gleichzeitig geöffneter Dokumente? Für keines der beiden Produkte gibt es eine allgemeingültige Kennzahl, da Dokumentkomplexität, Schriftarten, Konvertierungsaufwand, Speicherlatenz, Browserverhalten, Reverse-Proxys und die Anzahl gleichzeitig geöffneter Dokumente das Ergebnis beeinflussen.

Stand Oktober 2026 veröffentlicht keiner der beiden Anbieter einen aktuellen, direkten Vergleichstest. Das ist wichtig. Ein fairer Vergleich sollte daher zwei Arten von Daten unterscheiden: die Dimensionierungsempfehlungen der Anbieter, die Ihnen zeigen, welche Ressourcen Sie für jedes Projekt bereitstellen sollten, und einen reproduzierbaren Latenz-/Ressourcentest, der auf identischer Hardware durchgeführt wird. Der untenstehende Testplan liefert Ihnen Ergebnisse, die Sie für Ihre eigene Implementierung verwenden können, ohne anzunehmen, dass ein einzelnes Laborergebnis überall gültig ist.

Was die offizielle Ressourcenempfehlung tatsächlich aussagt

Die Anbieter veröffentlichen zwar hilfreiche Informationen zur Dimensionierung, die Angaben sind jedoch nicht direkt vergleichbar. Das SDK-Handbuch von Collabora enthält ein Beispiel für den Kubernetes/Helm-Produktionsbetrieb, das Ressourcenanforderungen von 4 CPUs und 6 GiB Arbeitsspeicher empfiehlt, mit Grenzwerten von 8 CPUs und 8 GiB. Im selben Handbuch wird die Funktion ` num_prespawn_childrenready` beschrieben, die Kindprozesse bereithält, sodass neue Sitzungen schneller gestartet werden können, allerdings auf Kosten von mehr Arbeitsspeicher. Weitere Informationen finden Sie im Handbuch des Collabora Online SDK . Die aktuelle Konfigurationsvorlage von Collabora bietet außerdem eine Begrenzung des Arbeitsspeicheranteils und Steuerungsmöglichkeiten für die gleichzeitige Ausführung pro Dokument. Der offizielle Quellcode des Projekts ist in der Collabora Online-Konfigurationsvorlage verfügbar .

ONLYOFFICE veröffentlicht detailliertere Referenzstufen für die Docs Community Edition in Docker. Die aktuellen Empfehlungen sehen mindestens 4 GB RAM vor und listen Referenzkonfigurationen auf: einen 2,8-GHz-Kern für weniger als 100 gleichzeitig aktive Benutzer, zwei Kerne für 100–200 und vier Kerne für 200–400, wobei in diesen Referenzzeilen jeweils 4 GB RAM benötigt werden. Der Anbieter weist ausdrücklich darauf hin, dass die tatsächliche Kapazität von Anzahl, Art und Größe der Dokumente abhängt. Weitere Informationen finden Sie in den Docker-Anforderungen für die ONLYOFFICE Docs Community Edition .

Warum ein Screenshot des Leerlaufspeichers kein Benchmark ist

Ein gängiger Vergleich besteht darin, beide Container zu starten, keine Dokumente zu öffnen und denjenigen mit dem geringeren RAM-Verbrauch als Sieger zu bezeichnen. Dies misst jedoch nur den grundlegenden Ressourcenverbrauch. Die wirklich wichtigen Vorgänge werden dabei außer Acht gelassen: das Öffnen einer Datei, deren Konvertierung (falls erforderlich), das Rendern von Seiten oder Tabellenblättern, das Übertragen von Änderungen, das Neuberechnen von Tabellenkalkulationen, die Bedienung durch mehrere Bearbeiter und das Speichern des Ergebnisses.

Das Prozessmodell von Collabora kann untergeordnete Prozesse im Voraus bereitstellen. Dadurch kann die Leerlaufzeit verkürzt und gleichzeitig die Wartezeit bis zur Verwendung eines Dokuments reduziert werden. ONLYOFFICE trennt die Dokumentbearbeitung von Diensten wie der Konvertierung. Die Architekturdokumentation beschreibt den Dokumenteditor, den Bearbeitungsdienst, den Befehlsdienst, den Konvertierungsdienst und den Builder-Dienst. Siehe Funktionsweise von ONLYOFFICE Docs . Anders ausgedrückt: Der Basis-RSS-Wert ist zwar eine nützliche Kennzahl für den Betrieb, reicht aber nicht aus, um die vom Benutzer wahrgenommene Geschwindigkeit vorherzusagen.

Ein fairer Testaufbau für Ressourcen und Latenz

Führen Sie die beiden Produkte nacheinander auf demselben Host oder auf zwei identisch konfigurierten VMs aus. Vermeiden Sie es, das eine Produkt auf einem bereits vorgewärmten Host mit zwischengespeicherten Dateien und das andere direkt nach dem Start zu testen. Achten Sie darauf, dass Linux-Distribution, Docker-Version, CPU-Kontingent, Arbeitsspeicherlimit, Speicherklasse, Reverse-Proxy, TLS-Terminierung, Browserversion und Dokumentenspeicherpfad identisch sind.

Verwenden Sie drei Dokumenten-Workloads

• Textdokument: ein repräsentatives DOCX-Dokument mit Überschriften, Tabellen, Bildern, Änderungsverfolgung und Kommentaren.
• Tabellenkalkulation: eine XLSX-Datei mit Formeln, bedingter Formatierung, mehreren Arbeitsblättern und genügend Daten, um eine sinnvolle Neuberechnung auszulösen.
• Präsentation: eine PPTX-Datei mit Bildern, Diagrammen und mehreren Folien anstelle einer nahezu leeren Präsentation.

Verwenden Sie für beide Plattformen dieselben Dateien. Falls eine Datei in einem der Programme eine Formatkonvertierung erfordert, vermerken Sie dies, da die Konvertierung die Öffnungszeit erheblich verlängern kann. Optimieren Sie eine Datei nicht speziell für einen bestimmten Editor und betrachten Sie das Ergebnis anschließend als allgemeinen Plattformvergleich.

Testen Sie auf mehr als einer Parallelitätsstufe.

Eine praktikable Sequenz besteht aus 1, 5, 10 und 20 gleichzeitig geöffneten Editoren, gefolgt von einer höheren Stufe, die Ihrem erwarteten Spitzenwert entspricht. Ein „Benutzer“ sollte in jedem Durchlauf dasselbe bedeuten: ein Editor-Tab, in dem das Dokument vollständig geöffnet ist. Wiederholen Sie jede Stufe nach einem Aufwärmlauf mindestens dreimal und notieren Sie den Medianwert plus das langsamste Ergebnis. Dadurch wird die Wahrscheinlichkeit verringert, dass kurze Hintergrundspitzen das Ergebnis verfälschen.

Zu erfassende Ressourcenkennzahlen

Docker bietet eine herstellerneutrale Telemetrie-Basisschicht. Die offizielle Docker-Statistikdokumentation erklärt, dass docker statsCPU-Auslastung, Speichernutzung, Netzwerk-E/A, Block-E/A und Prozess-IDs (PIDs) erfasst werden. Es können sowohl ein Live-Stream während der Arbeitslast als auch eine Stichprobe ohne Stream an definierten Kontrollpunkten aufgezeichnet werden.

docker stats collabora --no-stream
docker stats onlyoffice --no-stream

Für jede Parallelitätsstufe wird der Leerlaufspeicher vor dem Öffnen von Prozessen, der Speicherverbrauch im Normalzustand nach dem Öffnen aller Dokumente, die maximale CPU-Auslastung beim Öffnen, die CPU-Auslastung nach dem Stabilisierungszustand der Sitzungen und der Speicherverbrauch nach dem Schließen jeder Sitzung erfasst. Außerdem wird beobachtet, ob sich der Speicherverbrauch nach einer Abkühlphase wieder dem Ausgangswert annähert. Ein höherer Wert nach dem Test deutet nicht automatisch auf ein Speicherleck hin – Caches und gemeinsam genutzter Speicher können weiterhin nutzbar sein –, aber ein kontinuierlich ansteigender Wert über wiederholte identische Zyklen hinweg sollte untersucht werden.

Vergleichen Sie nicht nur die prozentualen Containeranteile, wenn ein Container ein anderes CPU- oder Speicherlimit hat. Notieren Sie die tatsächlichen Host- oder Cgroup-Limits zusammen mit den Benchmark-Ergebnissen. Die Speicherangabe von Docker unter Linux berücksichtigt zudem die Cache-Verwaltung. Verwenden Sie daher für beide Produkte dieselbe Docker- und Cgroup-Umgebung.

Wie man die Öffnungslatenz misst

Definieren Sie die Öffnungslatenz vor dem Testen. Eine sinnvolle Definition ist die Zeitspanne von der Öffnung durch den Benutzer bis zu dem Zeitpunkt, an dem der Editor sichtbar eingabebereit ist und der Dokumentinhalt sich so weit stabilisiert hat, dass mit dem Tippen begonnen werden kann. Messen Sie denselben Marker für beide Produkte. Eine einfache Bildschirmaufnahme mit Zeitstempeln ist vergleichbarer als die Verwendung produktspezifischer interner Ereignisse.

Erfassen Sie zwei Arten der Öffnungslatenz. Die Kaltstart-Latenz beginnt nach einem Neustart des Office-Containers und dem Löschen der Testsitzung. Die Warmstart-Latenz wiederholt dieselbe Datei, ohne den Dienst neu zu starten. Die Prespawn-Einstellung von Collabora macht diese Unterscheidung besonders wichtig, da mehr wartende Kindprozesse die Startverzögerung zwar verringern, aber gleichzeitig den Speicherverbrauch erhöhen können. Wenn Sie die Einstellung anpassen num_prespawn_children, listen Sie deren Wert zusammen mit den Ergebnissen auf, anstatt ihn auszublenden.

Wie man die Latenz in der Zusammenarbeit misst

Für die gemeinsame Echtzeitbearbeitung ist nicht der übliche ICMP-Ping als Messgröße aussagekräftig. Messen Sie die Verzögerung zwischen einer Änderung in Browser A und der sichtbaren Änderung in Browser B. Verwenden Sie zwei separate Browserprofile oder Rechner und synchronisieren Sie deren Uhren. Zeichnen Sie 20–50 einfache Änderungen auf, z. B. das Hinzufügen eines Zeichens im selben Absatz, und berechnen Sie anschließend den Median und das 95. Perzentil der sichtbaren Ausbreitungsverzögerung.

Die offizielle Beschreibung der gemeinsamen Bearbeitung in ONLYOFFICE bestätigt, dass Änderungen vom Bearbeiter an den Dokumentenbearbeitungsdienst und anschließend an den anderen Bearbeiter übertragen werden. Siehe ONLYOFFICE-Workflow für die gemeinsame Bearbeitung . Die Serverkonfiguration enthält außerdem WebSocket-bezogene Einstellungen, darunter das Verhalten bei Wiederverbindungen und die maximale Nutzlastgröße, in der ONLYOFFICE-Serverkonfigurationsreferenz . Collabora ist ebenfalls auf persistenten WebSocket-Verkehr über den Reverse-Proxy angewiesen. Daher sollten Proxy-Pufferung, Timeout-Verhalten, TLS-Terminierung und Netzwerk-RTT als Teil der Testumgebung und nicht als Hintergrunddetails betrachtet werden.

Kontrollierte Netzwerkverzögerung hinzufügen

Wenn Ihre Benutzer remote arbeiten, wiederholen Sie den Kollaborationstest mit kontrollierter Roundtrip-Latenz (RTT) von beispielsweise 20 ms, 80 ms und 150 ms. Wenden Sie dieselbe Netzwerksteuerung auf beide Systeme an und dokumentieren Sie genau, wo sie eingeführt wird. Dadurch wird ein Unterschied sichtbar, der bei lokalen LAN-Benchmarks verborgen bleiben kann: Ein Redakteur mag eine RTT von 1–5 ms als optimal empfinden, während sie für Zweigstellen oder internationale Teams deutlich weniger unmittelbar ist.

Die Latenzzeit benötigt eine eigene Messgröße.

Das Speichern ist nicht gleichzusetzen mit einer Eingabeverzögerung. ONLYOFFICE beschreibt einen Workflow, bei dem der Bearbeitungsdienst die Änderungen kompiliert und nach Abschluss der Bearbeitung eine Rückmeldung an den Speicherdienst sendet. Die Dokumentation gibt eine standardmäßige Verzögerung von fünf Sekunden beim Konvertierungsstart an und weist darauf hin, dass die endgültige Dauer auch von der Konvertierungszeit, der Dateikomplexität und der Serverleistung abhängt. Siehe dazu die Dokumentation zum Speichern von Dateien in ONLYOFFICE . Das bedeutet, dass die Aussage „Speichern dauerte mehrere Sekunden“ nicht automatisch als Verzögerung bei der Interaktion interpretiert werden sollte.

Messen Sie bei beiden Produkten die Speicherdauer ab dem Zeitpunkt, an dem der letzte Bearbeiter seine Arbeit beendet hat, bis die aktualisierte Datei im Speichermedium bestätigt ist. Achten Sie darauf, dass sich die Speichermedien im selben Netzwerkpfad und auf demselben Datenträger befinden. Andernfalls kann eine langsame Nextcloud, ownCloud, ein langsamer Objektspeicher, eine langsame Datenbank oder ein langsamer Reverse-Proxy auf die Office-Suite zurückzuführen sein.

Ergebnisübersicht: Die wichtigsten Zahlen

Wie ist das Ergebnis zu interpretieren?

Wenn Collabora in Ihrer Konfiguration mehr Arbeitsspeicher im Leerlauf benötigt, dafür aber eine geringere Latenz beim Kaltstart aufweist, kann dies ein akzeptabler Kompromiss sein, sofern Benutzer häufig Dokumente öffnen und der Server über ausreichend Arbeitsspeicher verfügt. Zeigt ONLYOFFICE hingegen einen niedrigeren Basiswert, aber stärkere CPU-Spitzen während der Konvertierung, ist die verfügbare CPU-Leistung möglicherweise wichtiger als der Arbeitsspeicher. Auch umgekehrte Muster sind möglich; entscheidend ist, jede Ressourcenkurve mit einem für den Benutzer sichtbaren Ereignis in Verbindung zu bringen.

Bei einer kleinen, selbst gehosteten Installation sollten Sie sich auf den Speicherverbrauch im Leerlauf, die Zeit bis zum ersten Öffnen und die Frage konzentrieren, ob ein oder zwei große Dokumente Auslagerungen verursachen. Bei einer Unternehmensinstallation mit Dutzenden aktiven Bearbeitern priorisieren Sie den Anstieg des Speicherverbrauchs, die CPU-Auslastung, die Verzögerung beim gemeinsamen Bearbeiten (p95) und die Erholung nach Lastspitzen. Bei geografisch verteilten Benutzern können die Netzwerk-RTT und die Proxy-Konfiguration geringfügige serverseitige Unterschiede überwiegen.

Der beste Testsieger ist daher das Produkt, das innerhalb Ihres CPU- und RAM-Budgets bleibt und gleichzeitig Ihre Latenzvorgaben für Ihre realen Dokumente erfüllt. Die Angaben der Hersteller zur Leistungsdichte sind Ausgangspunkte, keine Benchmark-Ergebnisse. Führen Sie dieselbe Arbeitslast aus, halten Sie die Umgebung kontrolliert, veröffentlichen Sie Ihre Testkonfiguration zusammen mit den Ergebnissen und vermeiden Sie es, aus einer einzelnen Messung des Leerlaufspeichers eine Aussage über die Gesamtleistung zu ziehen.