Collabora Online versus ONLYOFFICE: RAM-geheugen en bewerkingslatentie meten

De CODE 26.04-release van Collabora Online, aangekondigd op 8 juni 2026, bevat wijzigingen in de interoperabiliteit en gebruiksvriendelijkheid van documenten, maar de release-opmerkingen bevatten geen gecontroleerde vergelijking van RAM-gebruik of latentie met ONLYOFFICE Docs. Voor een zinvolle beslissing kunt u het beste benchmarks uitvoeren met de exacte builds die u wilt implementeren op dezelfde host, met dezelfde documenten, browser, opslagplatform en gebruikersacties. De minimale vereisten van de leverancier zijn richtlijnen voor de planning, geen vergelijkende prestatieresultaten.

Deze referentieprocedure meet twee afzonderlijke zaken: het servergebruik en de tijd die gebruikers ervaren bij het openen en bewerken van een document. Het beweert niet dat één softwarepakket universeel sneller is. Bestandscomplexiteit, integratie, netwerkpad, lettertypen en gelijktijdige sessies kunnen het resultaat beïnvloeden.

Wat de gepubliceerde eisen u wel en niet kunnen vertellen.

De huidige Docker-vereisten van ONLYOFFICE vermelden minimaal 4 GB RAM en 4 GB swapgeheugen. Volgens de documentatie variëren de werkelijke vereisten afhankelijk van het aantal gelijktijdige actieve gebruikers, het type document en de grootte ervan. De handleiding voor het oplossen van Docker-problemen geeft aan dat 2-4 GB gebruik normaal kan zijn voor een paar dozijn actieve gebruikers. Dit zijn specifieke aanbevelingen voor ONLYOFFICE en geen directe vergelijking met Collabora.

Collabora geeft aan dat de hardwarevereisten afhangen van het aantal gelijktijdige gebruikers; in de FAQ wordt ook gewaarschuwd dat de prestaties afnemen naarmate het aantal gelijktijdige gebruikers toeneemt en dat dit afhankelijk is van de serverbronnen. CODE en het ondersteunde Collabora Online-product zijn verschillende implementatieopties. Een kleine CODE-test thuis is geen garantie voor een succesvolle implementatie van een productieabonnement, net zoals een test van ONLYOFFICE Community Edition niet automatisch representatief is voor een andere editie of architectuur. Noteer de editie, release, implementatiemethode en integratie voor elke test.

CODE 26.04 is een recente Collabora-release (oktober 2026). De release-opmerkingen beschrijven verbeteringen, waaronder documentinteroperabiliteit, maar geven geen cijfers over het RAM-gebruik per gebruiker of de bewerkingslatentie ten opzichte van ONLYOFFICE. Beschouw dit als een reden om de huidige, vastgezette builds te testen; beschouw het niet als bewijs van een snelheidsvoordeel.

Ontwikkel een eerlijke, herhaalbare test.

1. Gebruik dezelfde host en integratiepad. Geef elke suite dezelfde CPU- en geheugenlimieten, opslaglocatie, reverse proxy, TLS-configuratie en netwerkroute. Als u beide containers tegelijk uitvoert, concurreren ze om dezelfde resources; stop in plaats daarvan één suite, meet de prestaties en vervang deze vervolgens door de andere. Houd de host verder inactief.
2. Leg de softwareversies vast. Noteer de exacte imagetag of release, editie, Docker-versie, hostbesturingssysteem, browserversie en het verbonden platform. Vermijd variabele tags, bijvoorbeeld latesttijdens een vergelijking, omdat de software tussen de tests kan veranderen.
3. Bereid representatieve bestanden voor. Voeg een klein tekstbestand, een spreadsheet met formules en grafieken en het grootste of meest complexe bestand dat uw gebruikers doorgaans openen toe. Gebruik testkopieën, geen originele productiebestanden. Sla ze op via hetzelfde documentplatform dat voor normaal gebruik wordt gebruikt.
4. Houd de omstandigheden voor de klant constant. Gebruik dezelfde computer, browser, netwerkverbinding, schermgrootte en browserextensies. Sluit tabbladen die niet relevant zijn. Zorg er bij elke test voor dat het document volledig gesloten is voordat u een cold-open-meting start; voer vervolgens aparte warm-open-tests uit.
5. Bepaal de timing vóór het testen. Meet vanaf het moment dat het document wordt geopend totdat het volledig is weergegeven en bewerkt kan worden. Meet voor het meten van de bewerkingslatentie de tijd die nodig is voor een specifieke actie, zoals het typen van een korte zin en wachten tot deze verschijnt voor een tweede medewerker. Registreer het resultaat van elke testronde in plaats van af te gaan op één enkele weergave.

Meet het servergebruik en de voor de gebruiker zichtbare vertraging.

Geheugen en CPU

Leg een basislijn vast voor inactiviteit nadat de service is gestabiliseerd. Registreer vervolgens het geheugen- en CPU-gebruik van de container tijdens het openen van een bestand, het bewerken ervan en het open laten staan. Herhaal dit met meerdere gelijktijdige documenten en gebruikers op het niveau dat overeenkomt met uw verwachte werkbelasting. Voor Docker docker stats --no-streamwordt een momentopname van de resources weergegeven; gebruik deze herhaaldelijk tijdens elke fase of verzamel een tijdreeks met uw bestaande monitoringsysteem. Registreer ook het beschikbare geheugen op hostniveau, omdat het gerapporteerde gebruik van een container alleen niet aangeeft of de hele machine onder druk staat.

Rapporteer het piekgeheugen, het gemiddelde geheugen tijdens de actieve fase en het inactieve geheugen nadat documenten zijn gesloten. Houd hetzelfde bemonsteringsinterval aan. Stel het geheugen na één document niet gelijk aan de capaciteit voor een team: sessies, bestandsgrootte, renderingcomplexiteit en gelijktijdig bewerken spelen allemaal een rol. Als de implementatie Prometheus-metrics ondersteunt, verzamel deze dan consistent; Collabora documenteert Prometheus-compatibele metrics en live sessiebewaking. Gebruik voor ONLYOFFICE de gedocumenteerde containerdiagnostiek en resource-richtlijnen. Vermijd het vergelijken van de interne procesmetric van het ene product met het totale containergebruik van het andere product.

Open en bewerk de latentie

Voer voor elk representatief bestand minimaal vijf koude en vijf warme openingen uit. Rapporteer de mediaan en de langzaamste waargenomen tijd, niet alleen het beste resultaat. Een koude opening omvat werkzaamheden zoals het laden van het document en het weergeven van de eerste versie; een warme opening kan profiteren van caches. Gebruik dezelfde definitie van 'gereed' in beide editors.

Om de vertraging bij samenwerking te meten, verbindt u twee browsersessies en meet u de tijd tussen een specifieke bewerking in de ene sessie en de zichtbare update in de andere. Herhaal dezelfde actie meerdere keren, zowel zonder andere geopende documenten als onder de beoogde gelijktijdige belasting. Dit legt het gecombineerde effect vast van de editor, de server, de opslagintegratie en het netwerk. Als de browser en de server zich op verschillende netwerken bevinden, registreer dan de retourtijd; netwerkvertraging kan de verwerking van de editor zelf domineren.

Lees de resultaten zonder te overdrijven.

Kies de suite die voldoet aan uw latency-doelstelling en tegelijkertijd voldoende geheugen- en CPU-capaciteit overlaat bij realistische gelijktijdigheid. Als de resultaten dicht bij elkaar liggen, geef dan prioriteit aan documentcompatibiliteit, integratieondersteuning, gebruiksgemak en licenties. Voer dezelfde test opnieuw uit na een grote upgrade of infrastructuurwijziging. Voor gezaghebbende versie-specifieke details raadpleegt u de release-opmerkingen van Collabora CODE 26.04 , de Collabora Online FAQ en het overzicht van beveiliging en monitoring , evenals de Docker-vereisten voor de Community Edition van ONLYOFFICE en de handleiding voor probleemoplossing en resources voor Docker . Deze bronnen beschrijven elk product afzonderlijk; het betreft geen gecontroleerde vergelijkingstest.