Se la modifica collaborativa di ONLYOFFICE risulta lenta su un server Docker self-hosted, per prima cosa verifica se il ritardo dipende dal server, dal percorso di rete o da un documento specifico. Esegui le misurazioni della stessa sessione di modifica prima di apportare qualsiasi modifica: controlla l'utilizzo delle risorse del container e dell'host, quindi verifica che il proxy inverso gestisca correttamente la connessione dell'editor in tempo reale. Aggiungi CPU, memoria o ulteriore infrastruttura solo se le misurazioni indicano un limite di capacità.
Chiedete a due editor di aprire lo stesso documento e di apportare una piccola modifica contemporaneamente. Verificate se la digitazione risulta lenta per entrambi gli utenti, se uno dei due visualizza gli aggiornamenti in ritardo e se il problema si verifica con tutti i file o solo con un file di grandi dimensioni o complesso. Questo semplice confronto aiuta a distinguere un problema generale del servizio da un problema specifico del documento.
Sull'host Docker, identifica il container del Document Server e monitora il suo utilizzo delle risorse mentre si verifica il rallentamento:
docker ps
docker stats <container_name_or_id>Verificate la presenza di un utilizzo prolungato della CPU, di un eventuale avvicinamento della memoria al limite dell'host o del container, di attività di swap o di un container che si riavvia. Controllate anche lo spazio su disco dell'host e l'I/O se i salvataggi o il caricamento dei documenti si interrompono. Un picco di breve durata è meno indicativo di un collo di bottiglia che coincide con le modifiche lente. La pagina di risoluzione dei problemi di ONLYOFFICE per Docker indica che l'utilizzo della memoria aumenta con i documenti aperti e gli utenti simultanei; suggerisce un valore normale di 2-4 GB per un server con alcune decine di utenti attivi, ma non si tratta di una garanzia di dimensionamento universale.
Ricorda che ONLYOFFICE considera un utente attivo simultaneo come un utente con un documento aperto, sia in fase di modifica che di visualizzazione. Confronta il numero massimo di utenti aperti in modalità di modifica con i requisiti di sistema Docker della Community specifici per l'edizione . I dati pubblicati sono configurazioni di riferimento e la documentazione indica che la capacità effettiva dipende dal tipo e dalle dimensioni del documento.
Se l'editor si carica ma i co-editor si disconnettono ripetutamente, oppure se il ritardo si verifica solo tramite il tuo URL pubblico, controlla il proxy inverso prima di aggiungere risorse al server. WebSocket è la connessione persistente utilizzata per il traffico dell'editor in tempo reale. Un proxy che chiude o non riesce ad aggiornare tale connessione può causare ritardi nelle modifiche o richiedere continue disconnessioni.
Controlla i log di accesso e di errore del proxy durante una sessione con latenza elevata. Verifica che la tua configurazione inoltri le intestazioni HTTP Upgrade e Connection e che preservi l'host e il protocollo originali. Per NGINX, confronta la tua configurazione con gli esempi di proxy ufficiali di ONLYOFFICE ; la documentazione specifica le intestazioni inoltrate X-Forwarded-Proto. X-Forwarded-HostNon incollare un esempio integralmente se la terminazione TLS, il prefisso del percorso o la topologia del proxy sono diversi.
Eseguire un test anche da un client sulla stessa LAN e dal normale percorso remoto. Se la sessione LAN è reattiva mentre il percorso pubblico è lento, verificare la presenza di problemi con proxy, firewall, VPN, DNS o latenza WAN. Se entrambi i percorsi presentano ritardi contemporaneamente, è più probabile che il problema sia legato al carico sul server. Gli strumenti per sviluppatori del browser possono essere d'aiuto: disconnessioni ripetute tramite WebSocket indicano un problema di gestione della connessione, mentre una connessione stabile con modifiche lente su un host saturo indica un problema di capacità o di carico di lavoro.
ONLYOFFICE offre la co-editing veloce, che è l'impostazione predefinita e mostra le modifiche degli altri utenti in tempo reale, e la co-editing rigorosa, che mantiene le modifiche in sospeso finché un utente non le salva. La documentazione sulla co-editing descrive la differenza nella modalità di visualizzazione delle modifiche. La modalità rigorosa è adatta ai team che preferiscono rivedere e applicare le modifiche in blocco; la modalità veloce è la scelta ideale quando è importante avere una visibilità condivisa immediata.
Cambiare modalità non risolve un problema di CPU satura, di memoria limitata o di routing WebSocket interrotto. Considerate la modalità come una preferenza di collaborazione e confrontate lo stesso numero di file e utenti in entrambe le modalità solo se il vostro team deve decidere quale flusso di lavoro sia più adatto. Evitate di presentare il cambio di modalità come un miglioramento garantito delle prestazioni.
Se si verificano rallentamenti tra documenti e utenti mentre la CPU rimane satura, la memoria è limitata o i container vengono riavviati, innanzitutto assegnare al Document Server risorse host adeguate e verificare che i limiti di Docker non compromettano le prestazioni dell'host. Quindi, eseguire nuovamente il test. La documentazione di riferimento di Docker per la Community Edition elenca 4 GB di RAM e requisiti di archiviazione che variano in base al numero di utenti simultanei; per oltre 400 utenti attivi simultanei, raccomanda una distribuzione cluster e suggerisce Kubernetes. Utilizzare questi valori come riferimento per la pianificazione, non come garanzia che un determinato server supporterà uno specifico carico di lavoro.
Per installazioni di piccole dimensioni, aumentare la CPU o la memoria disponibili è solitamente più semplice da gestire rispetto alla suddivisione dei servizi su più host. Per un'elevata concorrenza continuativa, servizi separati o in cluster possono offrire maggiore margine di manovra, ma comportano dipendenze di rete, configurazione, monitoraggio e potenziali punti di errore. L'esempio Compose ufficiale di ONLYOFFICE include un controllo di integrità per l'endpoint del server documenti; è consigliabile utilizzare congiuntamente l'integrità del container e la reattività dell'applicazione, anziché presumere che un container in esecuzione implichi un percorso di modifica funzionante. Durante la diagnosi, è importante mantenere la versione dell'immagine bloccata in modo che un aggiornamento della distribuzione non comprometta le misurazioni prima e dopo.
Ripeti la modifica originale a due utenti utilizzando lo stesso documento, lo stesso percorso client e un carico approssimativo. Verifica che la digitazione sia reattiva per entrambi gli utenti, che le modifiche vengano visualizzate in modo coerente nella modalità di co-editing selezionata e che le disconnessioni o i riavvii del container siano cessati. Monitora il processo docker statsdurante il nuovo test e controlla i log del proxy per verificare se il problema era correlato alla connessione. Se un piccolo test funziona ma le sessioni nelle ore di punta continuano a presentare rallentamenti, raccogli l'immagine/versione del container, le versioni dell'host e di Docker, i volumi montati, i grafici delle risorse e i log pertinenti prima di modificare ulteriori impostazioni; la guida ufficiale al debug logging spiega come abilitare i log di debug temporanei in Docker. Riduci il livello di dettaglio del logging dopo aver raccolto le prove, poiché aumenta il volume dei log.
Utilizzate i risultati per scegliere il compromesso migliore: correggete il proxy quando le connessioni si interrompono, aumentate la capacità quando le misurazioni mostrano una pressione costante sulle risorse e lasciate il server inalterato quando è interessato un solo documento complesso, finché non avrete isolato quel carico di lavoro.
Individua le cause di rallentamento della modifica collaborativa, come la pressione sulle risorse di Docker, le connessioni proxy o il caricamento dei documenti, quindi scegli la soluzione più adatta ai tuoi dati.
Scegli dove deve terminare la connessione TLS, monta in modo sicuro un certificato e una chiave privata attendibili e verifica l'accesso HTTPS a un server ONLYOFFICE Docs in ambiente Docker.
Integra l'editor ONLYOFFICE nella tua applicazione PHP, firma la sua configurazione con JWT e salva i file modificati tramite una callback sicura.
Imposta la lingua di correzione per l'intero documento o per un testo selezionato, verifica che il controllo ortografico sia attivo e identifica i casi in cui manca un dizionario del server.
Abilita la funzione "Revisioni permanenti" per tutti gli utenti in un singolo documento ONLYOFFICE, verifica che le modifiche vengano registrate e comprendi i limiti di questa impostazione.
Verifica se Nginx, la rete Docker o un servizio interno di ONLYOFFICE stanno restituendo un errore 502, quindi controlla il server upstream corretto ed esegui un controllo di integrità.
Diagnostica gli errori di salvataggio di ONLYOFFICE controllando il percorso di callback di Nextcloud, i reindirizzamenti del proxy e i log di archiviazione, quindi verifica che il file modificato sia stato salvato correttamente.
Individua la causa dei crash di memoria di ONLYOFFICE, controlla i limiti di Docker, dimensiona correttamente la RAM del VPS, aggiungi lo swap in modo sicuro e verifica che i documenti si aprano e si salvino.
Distinguete i problemi di download del browser dagli errori di conversione lato server e utilizzate il registro o il controllo di accesso appropriato per far funzionare l'esportazione in PDF.
Abbina il segreto JWT utilizzato da ONLYOFFICE Docs e Nextcloud, applicalo in modo sicuro alle installazioni Docker o Linux e verifica la connessione senza compromettere l'autenticazione.
