Si la coédition d'ONLYOFFICE semble lente sur un serveur Docker auto-hébergé, commencez par déterminer si le délai provient du serveur, du réseau ou d'un document en particulier. Mesurez la vitesse de la même session d'édition avant toute modification : vérifiez l'utilisation des ressources du conteneur et de l'hôte, puis assurez-vous que votre proxy inverse transmet correctement la connexion à l'éditeur en direct. N'ajoutez du processeur, de la mémoire ou d'autres ressources d'infrastructure que si ces mesures indiquent une limite de capacité.
Demandez à deux personnes d'ouvrir le même document et d'y apporter une petite modification simultanément. Observez si la saisie est lente pour les deux utilisateurs, si l'un d'eux voit les modifications en retard et si le problème se produit avec tous les fichiers ou seulement avec un fichier volumineux ou complexe. Cette simple comparaison permet de distinguer un problème général du service d'une charge de travail spécifique à un document.
Sur l'hôte Docker, identifiez le conteneur du serveur de documents et observez son utilisation des ressources pendant que le délai se produit :
docker ps
docker stats <container_name_or_id>Surveillez la saturation prolongée du processeur, la mémoire proche de la limite de l'hôte ou du conteneur, l'activité du swap ou le redémarrage d'un conteneur. Vérifiez également l'espace disque et les E/S de l'hôte si les enregistrements ou le chargement de documents s'interrompent. Un pic bref est moins concluant qu'un goulot d'étranglement qui coïncide avec les ralentissements des modifications. La page de dépannage Docker d'ONLYOFFICE indique que l'utilisation de la mémoire augmente avec le nombre de documents ouverts et d'utilisateurs simultanés ; elle estime qu'il faut compter entre 2 et 4 Go pour un serveur avec quelques dizaines d'utilisateurs actifs, mais cette valeur n'est pas une garantie absolue.
N'oubliez pas que ONLYOFFICE comptabilise comme utilisateur actif simultané toute personne ayant un document ouvert, qu'elle le modifie ou le consulte. Comparez le nombre maximal d'éditeurs ouverts dans votre environnement avec la configuration système requise pour Community Docker, spécifique à votre édition . Les chiffres publiés correspondent à des configurations de référence ; la documentation précise que la capacité réelle dépend du type et de la taille des documents.
Si l'éditeur se charge mais que les co-éditeurs se déconnectent régulièrement, ou si le délai n'apparaît que sur votre URL publique, vérifiez le proxy inverse avant d'ajouter des ressources serveur. WebSocket est la connexion persistante utilisée pour le trafic de l'éditeur en direct. Un proxy qui ferme cette connexion ou ne parvient pas à la mettre à jour peut entraîner des modifications différées ou des reconnexions.
Vérifiez les journaux d'accès et d'erreurs du proxy lors d'une session instable. Assurez-vous que votre configuration transmet les en-têtes HTTP Upgrade et Connection et conserve l'hôte et le protocole d'origine. Pour NGINX, comparez votre configuration avec les exemples de proxy officiels d'ONLYOFFICE ; la documentation mentionne explicitement les en-têtes transmis X-Forwarded-Proto. X-Forwarded-HostNe copiez pas un exemple tel quel si votre terminaison TLS, votre préfixe de chemin ou votre topologie de proxy diffèrent.
Effectuez également un test depuis un client du même réseau local et depuis la route distante habituelle. Si la session locale est réactive malgré la lenteur de la route publique, examinez le proxy, le pare-feu, le VPN, le DNS ou la latence WAN. Si les deux routes présentent des ralentissements simultanément, une surcharge côté serveur est plus probable. Les outils de développement du navigateur peuvent s'avérer utiles : des déconnexions WebSocket répétées indiquent un problème de gestion des connexions, tandis qu'une connexion stable avec une édition lente sur un serveur saturé indique un problème de capacité ou de charge de travail.
ONLYOFFICE propose la coédition rapide, activée par défaut et affichant les modifications des autres utilisateurs en temps réel, et la coédition stricte, qui masque les modifications jusqu'à leur enregistrement. La documentation relative à la coédition explique la différence d'affichage des modifications. La coédition stricte convient aux équipes qui préfèrent examiner et appliquer les modifications par lots ; la coédition rapide est le choix idéal lorsque la visibilité partagée immédiate est essentielle.
Changer de mode ne résout pas les problèmes de saturation du processeur, de limite de mémoire ou de connexion WebSocket défaillante. Considérez le mode comme une préférence de collaboration, et comparez le nombre de fichiers et d'utilisateurs dans chaque mode uniquement si votre équipe cherche à déterminer le flux de travail le plus adapté. Évitez de présenter un changement de mode comme une amélioration garantie des performances.
Si des ralentissements surviennent entre les documents et les utilisateurs lorsque le processeur est saturé, que la mémoire est limitée ou que les conteneurs redémarrent, commencez par allouer des ressources suffisantes à Document Server et vérifiez que les limites de Docker ne sont pas insuffisantes. Relancez ensuite le test. La documentation de référence de Docker Community Edition indique 4 Go de RAM et des exigences de stockage variables selon le nombre d'utilisateurs simultanés ; pour plus de 400 utilisateurs actifs simultanés, elle recommande un déploiement en cluster et suggère Kubernetes. Utilisez ces chiffres comme référence pour la planification, et non comme une garantie qu'un serveur donné supportera une charge de travail spécifique.
Pour une petite installation, augmenter la puissance du processeur ou la mémoire disponible est généralement plus simple que de répartir les services sur plusieurs hôtes. En cas de forte concurrence soutenue, des services séparés ou en cluster peuvent offrir une plus grande marge de manœuvre, mais ils ajoutent des dépendances réseau, de la configuration, de la surveillance et des points de défaillance. L'exemple Compose officiel actuel d'ONLYOFFICE inclut un contrôle d'intégrité du point de terminaison du serveur de documents ; utilisez conjointement l'état du conteneur et la réactivité de l'application plutôt que de supposer qu'un conteneur en cours d'exécution garantit un environnement d'édition fonctionnel. Conservez la version de l'image fixe pendant le diagnostic afin qu'une mise à jour du déploiement ne fausse pas les mesures avant et après.
Répétez la modification à deux utilisateurs initiale en utilisant le même document, la même route client et une charge similaire. Vérifiez que la saisie est réactive pour les deux utilisateurs, que les modifications apparaissent de manière cohérente dans le mode de coédition sélectionné et qu'il n'y a plus de reconnexions ni de redémarrages de conteneur. Surveillez docker statsle processus pendant le nouveau test et consultez les journaux du proxy pour déterminer si le problème était lié à la connexion. Si un test rapide fonctionne, mais que les sessions aux heures de pointe présentent toujours des ralentissements, collectez l'image et la version du conteneur, les versions de l'hôte et de Docker, les volumes montés, les graphiques de ressources et les journaux pertinents avant de modifier d'autres paramètres ; le guide officiel de journalisation de débogage explique comment activer les journaux de débogage temporaires dans Docker. Réduisez le niveau de journalisation détaillé après avoir collecté les données, car il augmente le volume des journaux.
Utilisez le résultat pour choisir le compromis : corrigez le proxy lorsque les connexions sont interrompues, ajoutez de la capacité lorsque les mesures montrent une pression soutenue sur les ressources et laissez le serveur tranquille lorsqu’un seul document complexe est affecté, jusqu’à ce que vous ayez isolé cette charge de travail.
Identifiez si Document Server utilise un package Linux ou Docker, supprimez uniquement ses composants et vérifiez les données restantes sans supprimer par erreur les services partagés.
Identifiez les ralentissements de l'édition collaborative en fonction de la pression sur les ressources Docker, des connexions proxy ou de la charge des documents, puis choisissez la solution qui correspond à vos mesures.
Choisissez où le protocole TLS doit se terminer, montez un certificat et une clé privée de confiance en toute sécurité et vérifiez l'accès HTTPS à un serveur ONLYOFFICE Docs conteneurisé.
Intégrez l'éditeur ONLYOFFICE dans votre application PHP, signez sa configuration avec JWT et enregistrez les fichiers modifiés via une fonction de rappel sécurisée.
Définissez la langue de correction pour l'ensemble du document ou pour un texte sélectionné, vérifiez que la correction orthographique est activée et identifiez les cas où un dictionnaire serveur est manquant.
Activez le suivi des modifications permanent pour tous les utilisateurs d'un document ONLYOFFICE, vérifiez que les modifications sont bien enregistrées et comprenez les limites de ce paramètre.
Déterminez si Nginx, le réseau Docker ou un service interne ONLYOFFICE renvoie une erreur 502, puis vérifiez le serveur en amont corrigé et effectuez un contrôle d'intégrité.
Diagnostiquez les échecs d'enregistrement ONLYOFFICE en vérifiant la route de rappel Nextcloud, les redirections proxy et les journaux de stockage, puis vérifiez que le fichier modifié est bien conservé.
Identifiez la cause des plantages de mémoire d'ONLYOFFICE, vérifiez les limites de Docker, dimensionnez correctement la RAM du VPS, ajoutez du swap en toute sécurité et vérifiez que les documents s'ouvrent et s'enregistrent correctement.
Distinguez les problèmes de téléchargement du navigateur des erreurs de conversion côté serveur et utilisez le journal ou le contrôle d'accès approprié pour que votre exportation PDF fonctionne.
