Când co-editarea ONLYOFFICE se simte lentă pe un server Docker auto-găzduit, stabiliți mai întâi dacă întârzierea este cauzată de server, de calea de rețea sau de un anumit document. Măsurați aceeași sesiune de editare înainte de a modifica ceva: verificați utilizarea resurselor containerului și a gazdei, apoi confirmați dacă proxy-ul invers transmite corect conexiunea editorului live. Adăugați CPU, memorie sau mai multă infrastructură numai atunci când aceste măsurători arată o limită de capacitate.
Solicitați celor doi editori să deschidă același document și să facă o mică modificare în același timp. Observați dacă tastarea are întârzieri pentru ambii utilizatori, dacă un utilizator vede actualizările cu întârziere și dacă problema apare la fiecare fișier sau doar la un fișier mare sau complex. Această comparație simplă ajută la separarea unei probleme generale de servicii de o sarcină de lucru specifică unui document.
Pe gazda Docker, identificați containerul Document Server și urmăriți utilizarea resurselor sale în timp ce apare lag-ul:
docker ps
docker stats <container_name_or_id>Căutați o saturație susținută a procesorului, o memorie care se apropie de limita gazdei sau a containerului, activitate swap sau un container care repornește. Verificați, de asemenea, spațiul pe disc al gazdei și I/O dacă salvările sau încărcarea documentelor se întrerup. Un vârf scurt este mai puțin concludent decât un blocaj care se aliniază cu editările lente. Pagina de depanare ONLYOFFICE Docker menționează că utilizarea memoriei crește odată cu documentele deschise și utilizatorii concurenți; oferă 2–4 GB ca în mod normal pentru un server cu câteva zeci de utilizatori activi, dar aceasta nu este o garanție universală a dimensionării.
Rețineți că ONLYOFFICE consideră un utilizator activ simultan ca fiind cineva care are un document deschis, fie că îl editează, fie că îl vizualizează. Comparați numărul maxim de utilizatori deschiși ai editorului cu cerințele de sistem specifice ediției pentru Community Docker . Cifrele publicate sunt configurații de referință, iar documentația precizează că capacitatea reală depinde de tipul și dimensiunea documentului.
Dacă editorul se încarcă, dar co-editorii se deconectează în mod repetat sau dacă întârzierea apare doar prin adresa URL publică, verificați proxy-ul invers înainte de a adăuga resurse de server. WebSocket este conexiunea persistentă utilizată pentru traficul live al editorului. Un proxy care se închide sau nu reușește să actualizeze acea conexiune poate face ca editările să pară întârziate sau poate cauza reconexiuni.
Verificați jurnalele de acces și erori ale proxy-ului în timpul unei sesiuni cu întârziere. Confirmați că configurația dvs. redirecționează anteturile HTTP Upgrade și Connection și păstrează gazda și protocolul originale. Pentru NGINX, comparați configurația cu exemplele oficiale de proxy ONLYOFFICE ; documentația solicită în mod specific anteturile redirecționate X-Forwarded-Protoși X-Forwarded-Hostanteturile. Nu lipiți un exemplu complet dacă terminarea TLS, prefixul căii sau topologia proxy diferă.
Testați și de la un client de pe aceeași rețea locală (LAN) și de pe ruta normală la distanță. Dacă sesiunea LAN răspunde în timp ce ruta publică este lentă, investigați latența proxy-ului, firewall-ului, VPN-ului, DNS-ului sau WAN. Dacă ambele rute înregistrează întârzieri simultan, sarcina pe partea serverului devine mai probabilă. Instrumentele pentru dezvoltatorii de browsere vă pot ajuta: deconectările repetate ale WebSocket indică gestionarea conexiunii, în timp ce o conexiune stabilă cu editare lentă pe o gazdă saturată indică capacitate sau volum de lucru.
ONLYOFFICE oferă co-editare rapidă, care este setarea implicită și afișează editările altor utilizatori în timp real, și co-editare strictă, care păstrează modificările până când un utilizator le salvează. Documentația de co-editare descrie diferența în modul în care sunt afișate modificările. Strict se potrivește echipelor care preferă să revizuiască și să aplice modificările în loturi; Fast este alegerea naturală atunci când vizibilitatea partajată imediată contează.
Schimbarea modurilor nu repară un procesor saturat, o limită de memorie constrânsă sau o rută WebSocket întreruptă. Tratați modul ca o preferință de colaborare, apoi comparați același număr de fișiere și utilizatori în fiecare mod numai dacă echipa dvs. decide ce flux de lucru se potrivește. Evitați să prezentați o schimbare de mod ca o îmbunătățire garantată a performanței.
Dacă apare o întârziere între documente și utilizatori în timp ce procesorul rămâne saturat, memoria este constrânsă sau containerele repornesc, mai întâi oferiți Document Server resurse gazdă adecvate și verificați dacă limitele Docker nu subminează gazda. Apoi, testați din nou. Referința Docker publicată în ediția Community Edition listează cerințele de 4 GB de RAM și stocare care variază în funcție de banda de utilizatori concurenți; pentru mai mult de 400 de utilizatori activi concurenți, recomandă o implementare în cluster și indică Kubernetes. Folosiți aceste cifre ca referință de planificare, nu ca o promisiune că un anumit server va suporta o anumită sarcină de lucru.
Pentru o instalație mică, creșterea CPU-ului sau a memoriei disponibile este de obicei mai simplă de operat decât împărțirea serviciilor între gazde. Pentru o concurență ridicată susținută, serviciile separate sau grupate în cluster pot oferi mai mult spațiu, dar adaugă dependențe de rețea, configurație, monitorizare și puncte de eroare. Exemplul oficial actual Compose al ONLYOFFICE include o verificare a stării de funcționare pentru endpoint-ul Document Server; utilizați împreună starea de funcționare a containerului și timpul de răspuns al aplicației, în loc să presupuneți că un container care rulează înseamnă o cale de editare sănătoasă. Păstrați versiunea imaginii fixată în timpul diagnosticării, astfel încât o actualizare a implementării să nu confunde măsurătorile înainte și după.
Repetați editarea inițială cu doi utilizatori folosind același document, aceeași rută client și aceeași încărcare aproximativă. Confirmați că tastarea răspunde prompt pentru ambii editori, că modificările apar consecvent în modul de co-editare selectat și că reconexiunile sau repornirile containerului s-au oprit. Urmăriți docker statsîn timpul retestului și verificați jurnalele proxy dacă problema a fost legată de conexiune. Dacă un test mic funcționează, dar sesiunile din orele de vârf încă au întârzieri, colectați imaginea/versiunea containerului, versiunile gazdă și Docker, volumele montate, graficele de resurse și jurnalele relevante înainte de a modifica mai multe setări; ghidul oficial de depanare a înregistrărilor explică cum să activați jurnalele de depanare temporare în Docker. Dezactivați din nou înregistrarea detaliată după colectarea dovezilor, deoarece aceasta adaugă volum de jurnal.
Folosește rezultatul pentru a alege compromisul: corectează proxy-ul atunci când conexiunile se întrerup, adaugă capacitate atunci când măsurătorile arată o presiune susținută a resurselor și lasă serverul nesupravegheat atunci când este afectat un singur document complex, până când ai izolat sarcina de lucru respectivă.
Identificați dacă Document Server utilizează un pachet Linux sau Docker, eliminați doar componentele acestuia și verificați datele rămase fără a șterge serviciile partajate din greșeală.
Asociați editarea colaborativă lentă cu presiunea resurselor Docker, conexiunile proxy sau încărcarea documentelor, apoi alegeți soluția care corespunde măsurătorilor dvs.
Alegeți unde ar trebui să se termine TLS, montați în siguranță un certificat de încredere și o cheie privată și verificați accesul HTTPS la un server ONLYOFFICE Docs Dockerizat.
Încorporează editorul ONLYOFFICE în aplicația ta PHP, semnează configurația acestuia cu JWT și salvează fișierele editate printr-un apel invers securizat.
Setați limba de verificare pentru întregul document sau pentru textul selectat, confirmați că verificarea ortografică este activă și identificați când lipsește un dicționar de pe server.
Activați funcția de urmărire persistentă a modificărilor pentru toți utilizatorii dintr-un singur document ONLYOFFICE, verificați dacă modificările sunt înregistrate și înțelegeți limitele acestei setări.
Află dacă Nginx, rețeaua Docker sau un serviciu ONLYOFFICE intern returnează eroarea 502, apoi verifică verificarea corectă a upstream-ului și a stării de funcționare.
Diagnosticați salvările ONLYOFFICE eșuate verificând ruta de apel invers Nextcloud, redirecționările proxy și jurnalele de stocare, apoi verificați dacă fișierul editat persistă.
Găsiți cauza blocărilor de memorie ONLYOFFICE, verificați limitele Docker, dimensionați corect memoria RAM VPS, adăugați memoria swap în siguranță și verificați dacă documentele se deschid și se salvează.
Separă problemele legate de descărcarea browserului de erorile de conversie de pe server și folosește jurnalul corect sau verificarea accesului pentru a face exportul PDF să funcționeze.
