Soluciona el retraso en la coedición de ONLYOFFICE encontrando el cuello de botella.

Si la edición colaborativa de ONLYOFFICE se ralentiza en un servidor Docker autohospedado, primero determine si la demora se debe al servidor, a la ruta de red o a un documento en particular. Mida la misma sesión de edición antes de realizar cualquier cambio: compruebe el uso de recursos del contenedor y del host, y luego confirme que su proxy inverso transmite correctamente la conexión del editor en tiempo real. Añada CPU, memoria o infraestructura adicional solo cuando estas mediciones indiquen un límite de capacidad.

1. Reproduce el retraso y comprueba el servidor antes de ajustarlo.

Pida a dos editores que abran el mismo documento y realicen un pequeño cambio simultáneamente. Observe si ambos usuarios experimentan retrasos al escribir, si alguno ve las actualizaciones con retraso y si el problema se presenta con todos los archivos o solo con uno grande o complejo. Esta sencilla comparación ayuda a diferenciar un problema general del servicio de una carga de trabajo específica de un documento.

En el host de Docker, identifique el contenedor del servidor de documentos y observe su uso de recursos mientras se produce el retraso:

docker ps
 docker stats <container_name_or_id>

Busque saturación sostenida de la CPU, memoria cercana al límite del host o del contenedor, actividad de intercambio o reinicios de contenedores. Compruebe también el espacio en disco del host y la E/S si se producen pausas al guardar o cargar documentos. Un pico breve es menos concluyente que un cuello de botella que coincida con la lentitud en la edición. La página de solución de problemas de ONLYOFFICE Docker indica que el uso de memoria aumenta con documentos abiertos y usuarios concurrentes; recomienda entre 2 y 4 GB como valor normal para un servidor con varias docenas de usuarios activos, pero esto no garantiza un dimensionamiento universal.

Recuerda que ONLYOFFICE considera usuario activo simultáneo a quien tenga un documento abierto, ya sea editándolo o visualizándolo. Compara el número máximo de usuarios con un documento abierto con los requisitos del sistema de Docker de la comunidad específicos de la edición . Las cifras publicadas son configuraciones de referencia, y la documentación indica que la capacidad real depende del tipo y tamaño del documento.

2. Si los editores se reconectan, inspeccione el proxy y la ruta de red.

Si el editor se carga pero los coeditores se desconectan repetidamente, o si la demora solo se observa a través de su URL pública, revise el proxy inverso antes de agregar recursos al servidor. WebSocket es la conexión persistente que se utiliza para el tráfico del editor en tiempo real. Un proxy que cierra o no actualiza dicha conexión puede provocar retrasos en las ediciones o reconexiones.

Comprueba los registros de acceso y errores del proxy durante una sesión con latencia. Confirma que tu configuración reenvía los encabezados HTTP Upgrade y Connection, y que conserva el host y el protocolo originales. Para NGINX, compara tu configuración con los ejemplos oficiales de proxyX-Forwarded-Proto de ONLYOFFICE; la documentación especifica los encabezados reenviados X-Forwarded-Host. No copies y pegues un ejemplo tal cual si tu terminación TLS, prefijo de ruta o topología de proxy difieren.

También realice pruebas desde un cliente en la misma LAN y desde la ruta remota habitual. Si la sesión LAN responde bien mientras que la ruta pública es lenta, investigue el proxy, el firewall, la VPN, el DNS o la latencia de la WAN. Si ambas rutas presentan retrasos simultáneamente, es más probable que haya una sobrecarga en el servidor. Las herramientas para desarrolladores del navegador pueden ser útiles: las desconexiones repetidas de WebSocket indican problemas con la gestión de la conexión, mientras que una conexión estable con edición lenta en un host saturado apunta a problemas de capacidad o carga de trabajo.

3. Elija Rápido o Estricto para el flujo de trabajo, no como una solución para el servidor.

ONLYOFFICE ofrece edición colaborativa rápida, que es la opción predeterminada y muestra las ediciones de otros usuarios en tiempo real, y edición colaborativa estricta, que retiene los cambios hasta que un usuario los guarda. La documentación sobre edición colaborativa describe la diferencia en la visualización de los cambios. La edición estricta es ideal para equipos que prefieren revisar y aplicar cambios en lotes; la edición rápida es la opción natural cuando la visibilidad compartida inmediata es fundamental.

Cambiar de modo no soluciona una CPU saturada, un límite de memoria restringido ni una ruta WebSocket defectuosa. Considere el modo como una preferencia de colaboración y compare el mismo archivo y la cantidad de usuarios en cada modo solo si su equipo está decidiendo qué flujo de trabajo es el más adecuado. Evite presentar el cambio de modo como una mejora de rendimiento garantizada.

4. Escalar solo después de que las mediciones identifiquen la capacidad de presión.

Si se produce un retraso entre documentos y usuarios mientras la CPU permanece saturada, la memoria es limitada o los contenedores se reinician, primero asigne a Document Server los recursos de host necesarios y verifique que los límites de Docker no superen la capacidad del host. Luego, vuelva a realizar la prueba. La documentación de referencia de Docker Community Edition publicada indica que se requieren 4 GB de RAM y almacenamiento, requisitos que varían según el número de usuarios concurrentes; para más de 400 usuarios activos concurrentes, recomienda una implementación en clúster y apunta a Kubernetes. Utilice estas cifras como referencia para la planificación, no como garantía de que un servidor determinado soportará una carga de trabajo específica.

Para una instalación pequeña, aumentar la CPU o la memoria disponibles suele ser más sencillo que dividir los servicios entre hosts. Para una alta concurrencia sostenida, los servicios separados o en clúster pueden ofrecer mayor capacidad, pero añaden dependencias de red, configuración, monitorización y puntos de fallo. El ejemplo oficial actual de Compose de ONLYOFFICE incluye una comprobación de estado para el punto final del servidor de documentos; utilice el estado del contenedor y la capacidad de respuesta de la aplicación conjuntamente, en lugar de asumir que un contenedor en ejecución implica una ruta de edición saludable. Mantenga fija la versión de la imagen durante el diagnóstico para que una actualización de la implementación no confunda las mediciones previas y posteriores.

Verifique la solución con la misma prueba de edición.

Repita la edición original de dos usuarios utilizando el mismo documento, ruta de cliente y carga aproximada. Confirme que la escritura sea fluida para ambos editores, que los cambios aparezcan de forma consistente en el modo de coedición seleccionado y que las reconexiones o reinicios del contenedor hayan cesado. Observe docker statsdurante la nueva prueba y revise los registros del proxy para determinar si el problema estaba relacionado con la conexión. Si una prueba pequeña funciona, pero las sesiones en hora punta siguen presentando retrasos, recopile la imagen/versión del contenedor, las versiones del host y de Docker, los volúmenes montados, los gráficos de recursos y los registros relevantes antes de cambiar más configuraciones; la guía oficial de registro de depuración explica cómo habilitar los registros de depuración temporales en Docker. Vuelva a desactivar el registro detallado después de recopilar evidencia, ya que aumenta el volumen de registro.

Utilice el resultado para elegir la mejor solución: corrija el proxy cuando se interrumpan las conexiones, aumente la capacidad cuando las mediciones muestren una presión constante sobre los recursos y deje el servidor en paz cuando solo se vea afectado un documento complejo hasta que haya aislado esa carga de trabajo.