Résoudre les problèmes de latence lors de la coédition avec ONLYOFFICE sur un serveur Docker auto-hébergé

Si la coédition d'ONLYOFFICE vous semble lente sur un serveur Docker auto-hébergé, ne commencez pas par modifier des paramètres non documentés. Commencez par identifier trois causes principales : la charge sur les ressources du serveur, le comportement du proxy inverse/WebSocket et les erreurs liées au stockage ou au conteneur. La coédition repose sur une communication en temps réel et prolongée ; un serveur qui ouvre correctement les documents peut donc paraître lent lorsque plusieurs personnes saisissent du texte simultanément.

Ce guide utilise un exemple hypothétique : une petite équipe exécute ONLYOFFICE Docs dans un conteneur Docker derrière NGINX. Un ou deux utilisateurs peuvent modifier le document normalement, mais lorsque six personnes l'ouvrent simultanément, les mises à jour du curseur sont retardées et les modifications des autres utilisateurs apparaissent après un délai perceptible. Cet exemple est uniquement pédagogique et ne constitue ni un test de performance ni un compte rendu de déploiement réel.

En octobre 2026, ONLYOFFICE Docs 9.4 était la version en vigueur, comme indiqué dans le journal des modifications officiel. Cette version a également modifié l'architecture de l'édition Community en supprimant les dépendances à RabbitMQ et aux bases de données. Par conséquent, les conseils relatifs aux versions antérieures peuvent ne plus être adaptés à une version Community actuelle. Il est donc impératif de toujours vérifier votre édition et votre version installées avant de suivre les conseils d'optimisation publiés sur un ancien forum.

1. Mesurez le décalage avant de modifier quoi que ce soit.

Dans ce cas hypothétique, la première erreur serait de redémarrer des services au hasard en espérant que le problème de latence disparaisse. Il est préférable de mettre en place un test reproductible. Ouvrez le même document depuis plusieurs sessions de navigateur ou comptes de test, effectuez de brèves modifications et notez ce qui est retardé : les frappes au clavier à l’écran, le déplacement du curseur à distance, l’affichage du texte d’un autre utilisateur, l’état de l’enregistrement ou le chargement initial du document.

Ces symptômes indiquent différents goulots d'étranglement. Si l'éditeur se bloque dans le navigateur local, cela peut être dû à une surcharge du processeur côté client ou à un document très complexe. Si la saisie locale est instantanée mais que les modifications à distance sont retardées, examinez le chemin réseau et la session WebSocket. Si chaque action ralentit lorsque plusieurs documents sont ouverts, vérifiez l'utilisation du processeur, de la mémoire, du swap et des E/S disque du serveur.

ONLYOFFICE décrit son déploiement Docker et ses exigences minimales dans le guide d'installation officiel de Docker . Pour Docker Compose, veuillez suivre les instructions officielles de Docker Compose .

2. Vérifiez la charge du processeur et de la mémoire pendant que les utilisateurs effectuent des modifications.

Sur l'hôte Docker, exécutez :

docker stats

Surveillez le conteneur du serveur de documents pendant que le groupe de test effectue des modifications. Inspectez également les ressources de l'hôte à l'aide d'outils tels que :

free -h
uptime
vmstat 1
df -h

Les exigences officielles d'ONLYOFFICE concernant Docker spécifient au minimum 4 Go de RAM et 40 Go d'espace disque disponible pour les configurations documentées, ainsi que des exigences en matière de swap. Les recommandations pour les entreprises précisent également que la capacité dépend du nombre d'utilisateurs actifs simultanés et du nombre, du type et de la taille des documents. Ces chiffres constituent des valeurs de référence et ne garantissent pas qu'une configuration avec 4 Go assurera une collaboration fluide pour toutes les charges de travail.

Dans notre exemple, supposons docker statsque le conteneur du serveur de documents consomme systématiquement la majeure partie du processeur disponible lorsque six personnes saisissent du texte simultanément. C'est un indice significatif : l'ajout de délais d'expiration du proxy n'augmentera pas la consommation du processeur. L'étape suivante consiste à supprimer une limite de processeur Docker trop restrictive, à déplacer le conteneur vers un hôte plus rapide ou à réduire la charge de travail simultanée. En revanche, si la consommation du processeur reste modérée, poursuivez vos investigations avant d'acheter du matériel.

La référence officielle pour les recommandations de capacité publiées est la documentation ONLYOFFICE relative aux exigences système Docker .

3. Vérifiez l'espace disque, les points de montage et le cache de fichiers

La documentation Docker d'ONLYOFFICE indique les emplacements persistants, notamment /var/log/onlyofficepour les journaux et /var/lib/onlyofficele cache de fichiers. Vérifiez le système de fichiers sous-jacent à ces chemins, et pas seulement le système de fichiers racine de l'hôte.

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

Si un point de montage de liaison pointe vers un système de fichiers réseau lent ou un disque surchargé, l'ouverture, la conversion et l'activité du cache des documents peuvent engendrer de la latence. Si le disque est presque plein, il est conseillé de résoudre ce problème avant d'optimiser les applications. La documentation de dépannage Linux d'ONLYOFFICE mentionne spécifiquement un espace disque insuffisant comme cause possible des problèmes de conversion.

Le projet recommande également de stocker les données pertinentes en dehors du conteneur lorsque vous avez besoin de journaux persistants, d'un cache ou de services de base de données externes comme Redis ou RabbitMQ. Consultez le guide officiel sur les volumes Docker .

4. Vérifiez que le proxy inverse maintient la connexion en temps réel

De nombreux déploiements auto-hébergés placent ONLYOFFICE derrière NGINX, Apache, HAProxy ou Traefik. La documentation officielle du proxy ONLYOFFICE exige explicitement le transfert d'en-têtes tels que ` X-Forwarded-Proto@ X-Forwarded-HostHttpContent-Integer` et `@HttpContent-Integer`. La configuration fournie par ONLYOFFICE utilise également HTTP/1.1 et la gestion des mises à niveau WebSocket.

Pour NGINX, comparez votre configuration avec l'exemple officiel d'ONLYOFFICE plutôt que de copier-coller un extrait de code WebSocket générique provenant d'un autre produit. Voici un exemple représentatif :

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;

Les directives environnantes mapet les emplacements des proxys sont importants. Utilisez l'exemple complet du fournisseur pour votre topologie. Les configurations prises en charge sont décrites dans la documentation « Utilisation d'ONLYOFFICE derrière le proxy » .

Dans cette équipe hypothétique, supposons que l'hôte Docker dispose de suffisamment de ressources CPU et RAM, mais que le navigateur se reconnecte constamment au canal de collaboration via une couche NGINX d'entreprise. Cela pointe vers le chemin du proxy, et non vers la capacité de calcul du serveur de documents.

5. Confirmez la session WebSocket dans le navigateur.

Ouvrez les outils de développement de votre navigateur, sélectionnez l'onglet Réseau, filtrez le trafic WebSocket et rechargez l'éditeur. Une négociation WebSocket réussie affiche généralement 101 Switching Protocolsune connexion HTTP qui reste ouverte. Ne considérez pas une connexion WebSocket « en attente » persistante comme un échec en soi ; une connexion WebSocket active est censée rester ouverte.

Ce qui importe, ce sont les déconnexions/reconnexions répétées, les échecs de connexion, les erreurs de proxy ou les longues interruptions qui correspondent au délai de collaboration. Si les modifications à distance sont retardées aux mêmes moments que la reconnexion WebSocket, vous avez alors un problème réseau concret à résoudre.

Vérifiez la terminaison TLS, les délais d'inactivité des proxys, les règles de l'équilibreur de charge, les politiques WAF et tout intermédiaire susceptible de compromettre la préservation du trafic WebSocket. En présence de plusieurs couches de proxy, testez chaque saut au lieu de supposer que l'instance NGINX publique est la seule impliquée.

6. Vérifiez les conteneurs attendus et l'architecture spécifique à l'édition

Courir:

docker compose ps
# or
docker ps

Ne partez pas du principe que tous les déploiements ONLYOFFICE modernes doivent nécessairement utiliser la même configuration de conteneurs Redis, PostgreSQL ou RabbitMQ. La version est un facteur important. ONLYOFFICE indique qu'à partir de la version 9.4 (Docs), l'édition Community open source a été simplifiée en une architecture monoprocessus et ne dépend plus de RabbitMQ ni des bases de données. Les versions Enterprise, Developer, les anciens déploiements Community et les configurations Compose personnalisées peuvent différer.

Cela signifie qu'un article de dépannage de 2023 affirmant que « RabbitMQ est probablement le goulot d'étranglement » peut ne pas être pertinent pour une instance Community Edition actuelle. Identifiez l'image et la version que vous utilisez :

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

Le journal des modifications officiel de la documentation ONLYOFFICE indique la version 9.4.0, dont la date de sortie est le 20 mai 2026. L'annonce de la sortie de la documentation 9.4 par l'éditeur explique les changements apportés à l'architecture de l'édition Community.

7. Activez temporairement la journalisation de débogage et corrélez-la avec le décalage.

ONLYOFFICE fournit une variable d'environnement Docker documentée pour la journalisation de débogage. Pour un dépannage rapide, ajoutez :

DS_LOG_LEVEL=DEBUG

Ensuite, recréez ou redémarrez le conteneur concerné en fonction de votre méthode de déploiement et suivez les journaux :

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

La documentation officielle indique que les journaux Docker sont également disponibles à l' /var/log/onlyoffice/documentserverintérieur du conteneur, ainsi que dans le répertoire de journaux correspondant sur l'hôte, si celui-ci est monté. Le journal du convertisseur est utile en cas de lenteur lors de l'ouverture ou de la conversion de fichiers, tandis que les problèmes de co-édition doivent être analysés à l'aide des journaux du serveur de documents et des observations relatives au navigateur et au réseau.

Désactivez le mode DEBUG une fois les informations nécessaires collectées. La journalisation détaillée est destinée au diagnostic et ne doit pas être utilisée comme paramètre de performance permanent. Suivez la procédure du fournisseur décrite dans la documentation ONLYOFFICE concernant l'activation de la journalisation de débogage .

8. Mettez à jour avec précaution si vous utilisez une ancienne image.

Si le déploiement est nettement en retard par rapport à la version prise en charge, une mise à jour peut inclure des correctifs et des améliorations d'architecture. Cependant, « récupérer la dernière version et redémarrer » n'est pas une méthode sûre pour optimiser les performances d'un serveur de collaboration en production.

Commencez par noter l'étiquette de l'image actuelle, le fichier Compose, les paramètres JWT, les volumes montés, la configuration du proxy inverse et la configuration d'intégration. Utilisez une version fixe lorsque votre processus de modification exige une reproductibilité. Le guide d'installation Docker d'ONLYOFFICE explique comment spécifier une version particulière, et le journal des modifications officiel indique les changements apportés.

Avant d'arrêter intentionnellement un serveur de documents en production, suivez les instructions d'arrêt d'ONLYOFFICE pour votre édition et votre déploiement afin de garantir la sécurité des sessions d'édition actives. N'utilisez pas un document de référence contenant des modifications non enregistrées comme test de mise à niveau.

Comment ce cas hypothétique permet de cerner la véritable solution

Revenez à l'équipe d'exemple composée de six co-rédacteurs. Le résultat du dépannage dépend de vos observations :

Une base pratique pour les déploiements Docker

Pour une petite installation auto-hébergée, commencez par respecter les exigences minimales d'ONLYOFFICE, mais dimensionnez-la en fonction de votre activité réelle simultanée plutôt que du nombre total d'utilisateurs enregistrés. Conservez les journaux et le cache sur un stockage à latence prévisible. Évitez de limiter la puissance du processeur ou la mémoire, sauf si vous avez mesuré la charge de travail. Empêchez l'hôte Docker d'utiliser la mémoire virtuelle (swap) en cas de charge d'édition normale.

Placez ONLYOFFICE derrière un proxy inverse configuré selon les exemples fournis par le fournisseur, en conservant les mises à jour WebSocket et les en-têtes hôte/protocole transmis. Surveillez le serveur pendant la coédition, et pas seulement lorsqu'il est inactif. Pour des analyses plus approfondies, activez temporairement la journalisation DEBUG et corrélez les horodatages des journaux avec le comportement WebSocket du navigateur et les métriques du serveur.

Ce qu'il ne faut pas faire

• Ne modifiez pas les valeurs non documentées local.jsonsimplement parce qu'un message sur un forum les qualifie d'« optimisations de performance ».
• Ne présumez pas qu'une connexion WebSocket persistante affichée comme « en attente » est défaillante ; les connexions WebSocket de longue durée sont normales.
• N’ajoutez pas Redis, RabbitMQ ou PostgreSQL simplement parce qu’un ancien schéma de déploiement les utilisait. Vérifiez d’abord l’architecture de votre édition et de votre version.
• Ne désactivez pas la vérification TLS, la sécurité JWT ou les protections proxy pour réduire la latence.
• Ne comparez pas une métrique de serveur inactif avec la période pendant laquelle les utilisateurs signalent réellement des ralentissements.
• Ne mettez pas à niveau une instance de production sans préserver les volumes, la configuration et une procédure de restauration.

En résumé

Le problème de latence lors de la coédition dans ONLYOFFICE est plus facile à résoudre en l'abordant comme un problème système mesurable. Reproduisez le délai, observez l'utilisation des ressources Docker et hôte, vérifiez le stockage, assurez-vous que le navigateur maintient une connexion WebSocket stable via chaque proxy et consultez les journaux uniquement pour la période où la latence se produit. Une fois que vous savez si le goulot d'étranglement provient du calcul, de la mémoire, du disque, du réseau/proxy ou d'une modification spécifique de version/configuration, la correction devient ciblée et non plus aléatoire.

Pour plus de détails sur le déploiement actuel, utilisez la documentation d'installation Docker ONLYOFFICE , les exemples officiels de proxy inverse , le guide de journalisation de débogage et le journal des modifications officiel de la documentation .