Collabora Online vs ONLYOFFICE: Medición de la RAM y la latencia de edición.

La versión CODE 26.04 de Collabora Online, anunciada el 8 de junio de 2026, incluye mejoras en la interoperabilidad y la usabilidad de los documentos, pero sus notas de la versión no publican una comparación controlada de RAM ni de latencia con ONLYOFFICE Docs. Para tomar una decisión acertada, realice pruebas de rendimiento con las mismas versiones que planea implementar en el mismo servidor, con los mismos documentos, navegador, plataforma de almacenamiento y acciones del usuario. Los requisitos mínimos del proveedor son solo una guía de planificación, no resultados de rendimiento comparables.

Este procedimiento de referencia mide dos aspectos distintos: el uso de recursos del servidor y el tiempo que los usuarios perciben al abrir y editar un documento. No afirma que un conjunto de herramientas sea universalmente más rápido. La complejidad del archivo, la integración, la ruta de red, las fuentes y las sesiones concurrentes pueden modificar el resultado.

Lo que los requisitos publicados pueden —y no pueden— indicarle.

Los requisitos actuales de Docker de ONLYOFFICE indican al menos 4 GB de RAM y 4 GB de espacio de intercambio (swap). Su documentación señala que los requisitos reales varían según el número de usuarios activos simultáneos y el tipo y tamaño de los documentos. Su guía de solución de problemas de Docker indica que un uso de entre 2 y 4 GB es normal para unas pocas docenas de usuarios activos. Estas son especificaciones de dimensionamiento específicas de ONLYOFFICE, no una comparación directa con Collabora.

Collabora indica que los requisitos de hardware dependen del número de usuarios concurrentes; sus preguntas frecuentes advierten que el rendimiento disminuye a medida que aumenta el uso concurrente y depende de los recursos del servidor. CODE y el producto Collabora Online compatible son opciones de implementación distintas. Una pequeña prueba doméstica de CODE no predice una implementación de suscripción en producción, del mismo modo que una prueba de ONLYOFFICE Community Edition no representa automáticamente otra edición o arquitectura. Registre la edición, la versión, el método de implementación y la integración para cada ejecución.

A fecha de octubre de 2026, CODE 26.04 es una versión reciente de Collabora. Sus notas de lanzamiento describen mejoras, como la interoperabilidad de documentos, pero no cuantifican la RAM por usuario ni la latencia de edición en comparación con ONLYOFFICE. Esto sirve como motivo para probar las versiones más recientes y estables; no lo interprete como prueba de una ventaja en velocidad.

Diseñar una prueba justa y repetible.

1. Utilice el mismo host y la misma ruta de integración. Asigne a cada suite los mismos límites de CPU y memoria, ubicación de almacenamiento, proxy inverso, configuración TLS y ruta de red. Si ejecuta ambos contenedores simultáneamente, competirán por los mismos recursos; en su lugar, detenga una suite, analice su rendimiento y luego reemplácela con la otra. Mantenga el host inactivo.
2. Fije las versiones del software. Registre la etiqueta o versión exacta de la imagen, la edición, la versión de Docker, el sistema operativo del host, la versión del navegador y la plataforma conectada. Evite las etiquetas flotantes, como las que se usan latestdurante una comparación, ya que el software podría cambiar entre pruebas.
3. Prepare archivos representativos. Incluya un documento de texto breve, una hoja de cálculo con fórmulas y gráficos, y el archivo más grande o complejo que sus usuarios suelan abrir. Utilice copias de prueba duplicadas, no originales de producción. Guárdelos en la misma plataforma de documentos que utiliza habitualmente.
4. Mantenga las condiciones del cliente estables. Utilice el mismo ordenador, navegador, conexión de red, tamaño de pantalla y extensiones del navegador. Cierre las pestañas irrelevantes. Para cada prueba, asegúrese de que el documento esté completamente cerrado antes de iniciar una medición de apertura en frío; a continuación, realice pruebas de apertura en caliente por separado.
5. Defina los tiempos antes de realizar las pruebas. Mida desde que se abre el documento hasta que se renderiza por completo y permite la edición. Para medir la latencia de edición, registre el tiempo de una acción específica, como escribir una frase corta y esperar a que aparezca para un segundo colaborador. Registre el resultado de cada ejecución en lugar de basarse en una sola impresión.

Medir el uso del servidor y el retraso visible para el usuario

Memoria y CPU

Capture una línea base de inactividad después de que el servicio se haya estabilizado. Luego, registre la memoria y la CPU del contenedor mientras abre un archivo, lo edita y lo deja abierto. Repita el proceso con varios documentos y usuarios concurrentes en los niveles que coincidan con su carga de trabajo prevista. Para Docker, docker stats --no-streamse muestra una instantánea de los recursos en un momento dado; úsela repetidamente durante cada fase o recopile una serie temporal con su sistema de monitoreo existente. Registre también la memoria disponible a nivel del host, ya que el uso reportado por un contenedor por sí solo no muestra si toda la máquina está bajo presión.

Informe el consumo máximo de memoria, el consumo promedio durante la fase activa y el consumo inactivo tras el cierre de los documentos. Mantenga el mismo intervalo de muestreo. No equipare el consumo de memoria tras un documento con la capacidad para un equipo: las sesiones, el tamaño del archivo, la complejidad de la representación y la edición concurrente son factores importantes. Si la implementación admite métricas de Prometheus, recopílelas de forma consistente; Collabora documenta las métricas compatibles con Prometheus y la monitorización de sesiones en tiempo real. Para ONLYOFFICE, utilice su documentación sobre diagnósticos de contenedores y orientación de recursos. Evite comparar la métrica de proceso interna de un producto con el total del contenedor completo del otro.

Latencia de apertura y edición

Ejecute al menos cinco aperturas en frío y cinco aperturas en caliente para cada archivo representativo. Informe la mediana y el tiempo más lento observado, no solo el mejor resultado. Una apertura en frío incluye tareas como cargar el documento y renderizar su vista inicial; una apertura en caliente puede beneficiarse del uso de cachés. Utilice la misma definición de "listo" en ambos editores.

Para medir el retardo en la colaboración, conecte dos sesiones del navegador y mida el tiempo transcurrido desde una edición específica en una sesión hasta la actualización visible en la otra. Repita la misma acción varias veces, tanto sin otros documentos abiertos como bajo la carga concurrente prevista. Esto permite capturar el efecto combinado del editor, el servidor, la integración del almacenamiento y la red. Si el navegador y el servidor se encuentran en redes diferentes, registre las condiciones de ida y vuelta; el retardo de la red puede influir significativamente en el procesamiento del editor.

Lea los resultados sin exagerar.

Elija la suite que cumpla con su objetivo de latencia y que, a la vez, deje suficiente memoria y capacidad de CPU para una concurrencia realista. Si los resultados son similares, priorice la compatibilidad con documentos, la compatibilidad con la integración, la familiaridad operativa y las licencias. Vuelva a ejecutar la misma prueba después de una actualización importante o un cambio en la infraestructura. Para obtener detalles específicos de la versión, consulte las notas de la versión CODE 26.04 de Collabora , las preguntas frecuentes de Collabora Online y la descripción general de seguridad y supervisión , además de los requisitos de Docker de la edición Community de ONLYOFFICE y la guía de solución de problemas y recursos de Docker . Estas fuentes describen cada producto por separado; no constituyen una prueba comparativa directa controlada.