Voorkom vertragingen bij het samen bewerken in ONLYOFFICE door de oorzaak van het probleem te vinden.

Als het bewerken van documenten in ONLYOFFICE op een zelfgehoste Docker-server traag aanvoelt, controleer dan eerst of de vertraging te wijten is aan de server, het netwerkpad of een specifiek document. Meet dezelfde bewerkingssessie voordat u iets wijzigt: controleer het resourcegebruik van de container en de host en bevestig vervolgens dat uw reverse proxy de live editorverbinding correct doorgeeft. Voeg alleen CPU, geheugen of extra infrastructuur toe als uit deze metingen blijkt dat de capaciteit beperkt is.

1. Reproduceer de lag en controleer de server voordat je deze afstemt.

Vraag twee redacteuren om hetzelfde document te openen en tegelijkertijd een kleine wijziging aan te brengen. Let op of het typen bij beide gebruikers vertraagd is, of één van de gebruikers de updates later ziet en of het probleem zich voordoet bij elk bestand of alleen bij één groot of complex bestand. Deze eenvoudige vergelijking helpt om een ​​algemeen serviceprobleem te onderscheiden van een probleem met de werkdruk dat specifiek is voor een bepaald document.

Identificeer op de Docker-host de Document Server-container en observeer het resourcegebruik ervan gedurende de vertraging:

docker ps
 docker stats <container_name_or_id>

Let op aanhoudende CPU-belasting, geheugen dat de limiet van de host of container nadert, swap-activiteit of een container die opnieuw opstart. Controleer ook de schijfruimte en I/O van de host als het opslaan of laden van documenten stopt. Een korte piek is minder doorslaggevend dan een knelpunt dat samenvalt met de trage bewerkingen. De pagina voor probleemoplossing van ONLYOFFICE Docker vermeldt dat het geheugengebruik toeneemt met het aantal geopende documenten en gelijktijdige gebruikers; 2-4 GB wordt als normaal beschouwd voor een server met een paar dozijn actieve gebruikers, maar dit is geen universele garantie voor de benodigde capaciteit.

Houd er rekening mee dat ONLYOFFICE een gelijktijdig actieve gebruiker telt als iemand die een document open heeft, of dit nu bewerken of bekijken betreft. Vergelijk uw piekaantal geopende editors met de editiespecifieke systeemvereisten van Community Docker . De gepubliceerde cijfers zijn referentieconfiguraties en de documentatie geeft aan dat de werkelijke capaciteit afhangt van het documenttype en de documentgrootte.

2. Als editors opnieuw verbinding maken, controleer dan de proxy en het netwerkpad.

Als de editor wel laadt, maar mede-editors herhaaldelijk de verbinding verbreken, of als de vertraging alleen via uw openbare URL optreedt, controleer dan de reverse proxy voordat u serverbronnen toevoegt. WebSocket is de permanente verbinding die wordt gebruikt voor live editorverkeer. Een proxy die de verbinding verbreekt of niet kan upgraden, kan ervoor zorgen dat bewerkingen vertraagd lijken of dat er herverbindingen nodig zijn.

Controleer de toegangs- en foutenlogboeken van de proxy tijdens een sessie met vertraging. Controleer of uw configuratie de HTTP Upgrade- en Connection-headers doorstuurt en de oorspronkelijke host en het protocol behoudt. Vergelijk voor NGINX uw configuratie met de officiële proxy-voorbeelden van ONLYOFFICE ; de documentatie vermeldt specifiek X-Forwarded-Protode doorgestuurde X-Forwarded-Hostheaders. Kopieer geen voorbeeld zonder meer als uw TLS-terminatie, padvoorvoegsel of proxytopologie afwijkt.

Test de verbinding ook vanaf een client op hetzelfde LAN-netwerk en vanaf de normale externe route. Als de LAN-sessie snel reageert, maar de openbare route traag is, onderzoek dan de latentie van de proxy, firewall, VPN, DNS of WAN. Als beide routes tegelijkertijd vertraging oplopen, is een serverbelasting waarschijnlijker. De ontwikkelaarstools van de browser kunnen hierbij helpen: herhaaldelijk verbroken WebSocket-verbindingen wijzen op problemen met de verbindingsafhandeling, terwijl een stabiele verbinding met trage bewerking op een overbelaste server wijst op capaciteitsproblemen of een te hoge werkdruk.

3. Kies Snel of Strikt voor de workflow, niet als serveroplossing.

ONLYOFFICE biedt twee opties: Snel samen bewerken, de standaardinstelling waarbij de bewerkingen van andere gebruikers in realtime worden weergegeven, en Strikt samen bewerken, waarbij wijzigingen worden vastgehouden totdat een gebruiker ze opslaat. De documentatie over samen bewerken beschrijft het verschil in de weergave van wijzigingen. Strikt is geschikt voor teams die wijzigingen liever in batches bekijken en toepassen; Snel is de logische keuze wanneer directe, gedeelde zichtbaarheid belangrijk is.

Het wisselen van modus lost geen probleem op met een overbelaste CPU, een geheugenlimiet of een defecte WebSocket-verbinding. Beschouw de modus als een voorkeur voor samenwerking en vergelijk hetzelfde bestand en aantal gebruikers in elke modus alleen als uw team bepaalt welke workflow het beste werkt. Vermijd het presenteren van een moduswissel als een gegarandeerde prestatieverbetering.

4. Weeg pas nadat de metingen de capaciteitsdruk hebben vastgesteld.

Als er vertraging optreedt tussen documenten en gebruikers terwijl de CPU overbelast blijft, het geheugen beperkt is of containers opnieuw opstarten, geef de Document Server dan eerst voldoende hostbronnen en controleer of de Docker-limieten de host niet onderbenutten. Test het vervolgens opnieuw. De gepubliceerde Docker-referentie voor de Community Edition vermeldt 4 GB RAM en opslagvereisten die variëren afhankelijk van het aantal gelijktijdige gebruikers; voor meer dan 400 gelijktijdige actieve gebruikers wordt een clusterimplementatie aanbevolen en wordt Kubernetes aangewezen. Gebruik deze cijfers als planningsrichtlijn, niet als garantie dat een bepaalde server een specifieke workload aankan.

Voor een kleine installatie is het vergroten van de beschikbare CPU of het geheugen meestal eenvoudiger dan het verdelen van services over verschillende hosts. Voor langdurig hoge gelijktijdigheid kunnen aparte of geclusterde services meer speelruimte bieden, maar ze brengen wel netwerkafhankelijkheden, configuratie, monitoring en faalpunten met zich mee. Het huidige officiële Compose-voorbeeld van ONLYOFFICE bevat een gezondheidscontrole voor het eindpunt van de Document Server; gebruik de containerstatus en de responsiviteit van de applicatie samen in plaats van ervan uit te gaan dat een draaiende container een gezond bewerkingspad betekent. Houd de imageversie vast tijdens de diagnose, zodat een update van de implementatie de metingen van voor en na de wijziging niet verstoort.

Controleer de oplossing met dezelfde bewerkingstest.

Herhaal de oorspronkelijke bewerking met twee gebruikers met hetzelfde document, dezelfde clientroute en een vergelijkbare belasting. Controleer of het typen voor beide editors responsief aanvoelt, of de wijzigingen consistent worden weergegeven in de geselecteerde co-editingmodus en of er geen herverbindingen of herstarts van de container meer optreden. Observeer docker statstijdens de hertest de proxylogs als het probleem verbindingsgerelateerd was. Als een kleine test werkt, maar sessies tijdens piekuren nog steeds vertraging oplopen, verzamel dan de containerimage/versie, host- en Docker-versies, gekoppelde volumes, resourcegrafieken en relevante logs voordat u verdere instellingen wijzigt; de officiële handleiding voor debug-logging legt uit hoe u tijdelijke debug-logs in Docker kunt inschakelen. Schakel de uitgebreide logging weer uit nadat u bewijsmateriaal hebt verzameld, omdat dit extra logvolume genereert.

Gebruik de uitkomst om de afweging te maken: corrigeer de proxy wanneer verbindingen verbroken worden, voeg capaciteit toe wanneer metingen aanhoudende resourcedruk aantonen en laat de server met rust wanneer slechts één complex document wordt beïnvloed totdat u die specifieke belasting hebt geïsoleerd.