Remediați lag-ul de co-editare ONLYOFFICE pe un server Docker auto-găzduit

Dacă editarea în comun cu ONLYOFFICE se simte lentă pe un server Docker auto-găzduit, nu începeți prin a modifica parametrii editorului nedocumentați. Mai întâi, separați problema în trei domenii măsurabile: presiunea resurselor serverului, comportamentul reverse-proxy/WebSocket și erorile la nivel de stocare sau container. Editarea în comun depinde de comunicarea în timp real, de lungă durată, astfel încât un server care deschide documentele cu succes poate părea totuși lent atunci când mai multe persoane tastează simultan.

Acest ghid folosește un exemplu ipotetic pe tot parcursul: o echipă mică rulează ONLYOFFICE Docs în Docker în spatele NGINX. Unul sau doi utilizatori pot edita normal, dar când șase persoane deschid același document, actualizările cursorului ajung târziu, iar modificările altor utilizatori apar după o pauză vizibilă. Acest exemplu este doar un scenariu didactic, nu un test de performanță sau un raport al unei implementări reale.

Începând cu octombrie 2026, ONLYOFFICE Docs 9.4 este versiunea curentă listată în jurnalul oficial de modificări. Versiunea 9.4 a modificat și arhitectura ediției Community prin eliminarea dependențelor de RabbitMQ și baze de date, astfel încât sfaturile scrise pentru versiunile mai vechi ar putea să nu se mai potrivească cu un container Community Edition curent. Confirmați întotdeauna ediția și versiunea instalate înainte de a copia sfaturi de optimizare dintr-o postare mai veche pe forum.

1. Măsurați lag-ul înainte de a schimba ceva

În cazul ipotetic, prima greșeală ar fi să reporniți serviciile aleatorii și să sperați că întârzierea va dispărea. În schimb, creați un test repetabil. Deschideți același document din mai multe sesiuni de browser sau conturi de testare, tastați scurte modificări și notați ce este întârziat: apăsările de taste pe ecranul local, mișcarea cursorului la distanță, apariția textului altui utilizator, starea de salvare sau încărcarea inițială a documentului.

Aceste simptome indică diferite blocaje. Dacă editorul în sine se blochează în browserul local, poate fi implicat procesorul de pe partea clientului sau un document foarte complex. Dacă tastarea locală este imediată, dar editările la distanță ajung târziu, examinați calea de rețea și sesiunea WebSocket. Dacă fiecare acțiune încetinește atunci când sunt deschise mai multe documente, inspectați procesorul serverului, memoria, swap-ul și I/O-ul pe disc.

ONLYOFFICE descrie implementarea Docker și cerințele de bază în ghidul oficial de instalare Docker . Pentru Docker Compose, utilizați instrucțiunile oficiale Docker Compose .

2. Verificați presiunea CPU și a memoriei în timp ce utilizatorii editează

Pe gazda Docker, executați:

docker stats

Urmăriți containerul Document Server în timp ce grupul de testare editează. De asemenea, inspectați resursele gazdă cu instrumente precum:

free -h
uptime
vmstat 1
df -h

Cerințele oficiale Docker ale ONLYOFFICE specifică cel puțin 4 GB de RAM și cel puțin 40 GB de spațiu liber pe disc pentru configurațiile documentate, împreună cu cerințele swap. De asemenea, îndrumările pentru întreprinderi precizează clar că capacitatea depinde de utilizatorii activi simultan și de numărul, tipul și dimensiunea documentelor. Aceste cifre sunt valori de referință, nu o promisiune că 4 GB vor oferi o colaborare fără probleme pentru fiecare sarcină de lucru.

În exemplul nostru, să presupunem docker statscă containerul Document Server consumă în mod repetat cea mai mare parte a procesorului disponibil ori de câte ori șase persoane tastează simultan. Aceasta este o dovadă semnificativă: adăugarea de timeout-uri proxy nu va crea mai mult procesor. Următorul pas este eliminarea unei limite CPU Docker prea restrictive, mutarea containerului pe o gazdă mai rapidă sau reducerea volumului de lucru concurent. În schimb, dacă procesorul rămâne modest, continuați să investigați înainte de a cumpăra hardware.

Referința oficială pentru îndrumările publicate privind capacitatea sunt cerințele de sistem Docker pentru ONLYOFFICE Docs .

3. Verificați spațiul pe disc, montările și memoria cache a fișierelor

Documentația Docker de la ONLYOFFICE identifică locațiile persistente, inclusiv /var/log/onlyofficepentru jurnale și /var/lib/onlyofficepentru memoria cache a fișierelor. Verificați sistemul de fișiere care susține aceste căi, nu doar sistemul de fișiere rădăcină al gazdei.

df -h
docker inspect documentserver --format '{json .Mounts}'

Dacă o montare bind indică un sistem de fișiere de rețea lent sau un disc supraîncărcat, deschiderea documentelor, conversia și activitatea din memoria cache pot adăuga latență. Dacă discul este aproape plin, remediați acest lucru înainte de a efectua optimizarea aplicației. Documentația de depanare Linux de la ONLYOFFICE identifică în mod specific spațiul insuficient pe disc ca o posibilă cauză a problemelor de conversie.

Proiectul recomandă, de asemenea, stocarea datelor relevante în afara containerului atunci când aveți nevoie de jurnale persistente, stocare în cache sau servicii externe de baze de date/Redis/RabbitMQ. Consultați ghidul oficial Docker pentru volume .

4. Verificați dacă proxy-ul invers păstrează conexiunea în timp real

Multe implementări auto-găzduite plasează ONLYOFFICE în spatele NGINX, Apache, HAProxy sau Traefik. Documentația oficială a proxy-ului ONLYOFFICE necesită în mod explicit anteturi redirecționate, cum ar fi X-Forwarded-Protoși X-Forwarded-Host. Configurația livrată de ONLYOFFICE utilizează, de asemenea, gestionarea actualizării HTTP/1.1 și WebSocket.

Pentru NGINX, comparați configurația cu exemplul oficial ONLYOFFICE, în loc să lipiți un fragment generic WebSocket dintr-un alt produs. Un model reprezentativ include:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Forwarded-Host $the_host;
proxy_set_header X-Forwarded-Proto $the_scheme;

Directivele exacte din jur mapși locațiile proxy contează. Folosește exemplul complet al furnizorului pentru topologia ta. Configurațiile acceptate sunt publicate în Documentația ONLYOFFICE din spatele proxy-ului .

În echipa ipotetică, să presupunem că gazda Docker are suficient CPU și RAM, dar browserul reconectează în mod repetat canalul de colaborare printr-un strat NGINX corporativ. Aceasta indică calea proxy, nu capacitatea de calcul a serverului de documente.

5. Confirmați sesiunea WebSocket în browser

Deschideți instrumentele pentru dezvoltatori din browser, selectați panoul Rețea, filtrați după traficul WebSocket și reîncărcați editorul. O confirmare de conectare WebSocket reușită afișează de obicei HTTP 101 Switching Protocolsși o conexiune care rămâne deschisă. Nu tratați un WebSocket „în așteptare” de lungă durată ca pe o eroare în sine; se așteaptă ca un WebSocket activ să rămână deschis.

Ceea ce contează este comportamentul repetat de deconectare/reconectare, handshake-urile eșuate, erorile de proxy sau intervalele lungi care se corelează cu întârzierea colaborării. Dacă editările la distanță au întârzieri în aceleași momente în care WebSocket-ul se reconectază, acum aveți o problemă concretă de rețea de rezolvat.

Verificați terminarea TLS, timeout-urile de inactivitate proxy, regulile load balancer-ului, politicile WAF și orice intermediar care ar putea să nu păstreze traficul WebSocket. Dacă există mai mult de un nivel proxy, testați fiecare hop în loc să presupuneți că instanța publică NGINX este singura implicată.

6. Verificați containerele așteptate și arhitectura specifică ediției

Aleargă:

docker compose ps
# or
docker ps

Nu presupuneți că fiecare implementare ONLYOFFICE modernă trebuie să aibă aceeași colecție de containere Redis, PostgreSQL sau RabbitMQ. Aici contează versiunea. ONLYOFFICE afirmă că, începând cu Docs 9.4, ediția open-source Community a fost simplificată într-o arhitectură cu un singur proces și a eliminat dependențele de RabbitMQ și bazele de date. Implementările Enterprise, Developer, Community mai vechi și stivele Compose personalizate pot diferi.

Asta înseamnă că un articol de depanare din 2023 care spune „RabbitMQ trebuie să fie blocajul” poate fi irelevant pentru o instanță curentă Community Edition. Identificați imaginea și versiunea pe care o rulați efectiv:

docker inspect documentserver --format '{.Config.Image}'
docker image ls onlyoffice/documentserver

Jurnalul oficial de modificări ONLYOFFICE Docs listează versiunea 9.4.0 cu data de lansare 20 mai 2026. Anunțul furnizorului privind lansarea Docs 9.4 explică modificarea arhitecturii Community Edition.

7. Activați temporar înregistrarea în jurnal a depanării și corelați-o cu lag-ul

ONLYOFFICE oferă o variabilă de mediu Docker documentată pentru înregistrarea în jurnal a erorilor. Pentru o fereastră scurtă de depanare, adăugați:

DS_LOG_LEVEL=DEBUG

Apoi recreați sau reporniți containerul relevant în funcție de metoda de implementare și urmați jurnalele:

docker logs -f documentserver
# Docker Compose:
docker compose logs -f documentserver

Documentația oficială menționează că jurnalele Docker sunt disponibile și în /var/log/onlyoffice/documentserverinteriorul containerului și în directorul de jurnale montat de gazdă corespunzător, dacă îl montați. Jurnalul convertorului este util atunci când deschiderea sau convertirea fișierelor este lentă, în timp ce problemele de co-autorizare ar trebui corelate cu jurnalele Document Server și observațiile browserului/rețelei.

Dezactivați din nou DEBUG după ce colectați ceea ce aveți nevoie. Înregistrarea detaliată este pentru diagnosticare, nu o setare permanentă de performanță. Urmați procedura furnizorului din Activarea înregistrării de depanare în ONLYOFFICE Docs .

8. Actualizați cu atenție dacă rulați o imagine veche

Dacă implementarea este semnificativ în urma liniei de lansare acceptate, o actualizare poate include remedieri de erori și îmbunătățiri ale arhitecturii. Însă „extrageți cea mai recentă versiune și reporniți” nu este o rețetă sigură pentru performanță pe un server de colaborare în producție.

Mai întâi înregistrați eticheta imaginii curente, fișierul compus, setările JWT, volumele montate, configurația reverse-proxy și configurația integrării. Folosiți o versiune fixată atunci când procesul de modificare necesită reproductibilitate. Ghidul de instalare Docker de la ONLYOFFICE documentează cum să specificați o anumită versiune, iar jurnalul oficial de modificări vă spune ce s-a modificat.

Înainte de a opri intenționat un server de documente aflat în producție, urmați instrucțiunile de oprire ONLYOFFICE pentru ediția și implementarea dvs., astfel încât sesiunile de editare active să fie gestionate în siguranță. Nu utilizați un document de referință care conține lucrări nesalvate ale utilizatorului ca test de actualizare.

Cum cazul ipotetic restrânge soluția reală

Reveniți la echipa exemplu cu șase co-editori. Rezultatul depanării depinde de ceea ce observați:

O bază practică pentru implementările Docker

Pentru o instalare mică, auto-găzduită, începeți cu valorile minime publicate pentru ONLYOFFICE, dar adaptați dimensiunea la activitatea concurentă reală, mai degrabă decât la numărul total de utilizatori înregistrați. Păstrați jurnalele persistente și memoria cache pe spațiu de stocare cu o latență previzibilă. Evitați limitele stricte ale CPU sau memoriei, cu excepția cazului în care ați măsurat volumul de lucru. Împiedicați ca gazda Docker să se schimbe sub sarcina normală de editare.

Plasați ONLYOFFICE în spatele unei configurații de proxy invers derivate din exemplele acceptate de furnizor, păstrând actualizările WebSocket și anteturile gazdă/protocol transmise. Monitorizați serverul în timpul co-editării efective, nu doar în timpul inactivității. Dacă aveți nevoie de dovezi mai detaliate, activați temporar înregistrarea în jurnal DEBUG și corelați marcajele temporale ale jurnalului cu comportamentul WebSocket al browserului și cu metricile gazdei.

Ce să nu faci

• Nu modificați valorile nedocumentate local.jsondoar pentru că o postare pe forum le numește „modificări de performanță”.
• Nu presupuneți că un WebSocket persistent afișat ca „în așteptare” este defect; se așteaptă WebSocket-uri cu durată lungă de viață.
• Nu adăugați Redis, RabbitMQ sau PostgreSQL doar pentru că o diagramă de implementare veche le-a folosit. Verificați mai întâi arhitectura ediției și versiunii dvs.
• Nu dezactivați verificarea TLS, securitatea JWT sau protecțiile proxy ca o scurtătură pentru a reduce latența.
• Nu comparați o metrică a serverului inactiv cu perioada în care utilizatorii raportează efectiv o întârziere.
• Nu actualizați o instanță de producție fără a păstra volumele, configurația și o cale de rollback.

Concluzie

Lag-ul de co-editare ONLYOFFICE este cel mai ușor de remediat atunci când îl tratați ca pe o problemă de sistem măsurabilă. Reproduceți întârzierea, observați resursele Docker și gazdă sub sarcină, verificați spațiul de stocare, confirmați că browserul menține un WebSocket sănătos prin fiecare proxy și inspectați jurnalele doar pentru fereastra de timp în care apare lag-ul. Odată ce știți dacă blocajul este legat de calcul, memorie, disc, comportamentul rețelei/proxy-ului sau o modificare specifică a versiunii/configurației, remedierea devine țintită în loc să fie speculativă.

Pentru detalii despre implementarea actuală, utilizați documentația de instalare ONLYOFFICE Docker , exemplele oficiale de reverse-proxy , ghidul de depanare în jurnal și jurnalul oficial de modificări din Documents .