Collabora Online vs ONLYOFFICE: Meça o uso de RAM e a latência de edição.

O lançamento do CODE 26.04 do Collabora Online, anunciado em 8 de junho de 2026, inclui melhorias na interoperabilidade e usabilidade de documentos, mas suas notas de lançamento não publicam uma comparação controlada de RAM ou latência com o ONLYOFFICE Docs. Para uma decisão útil, realize testes de desempenho com as mesmas versões que você planeja implantar no mesmo host, com os mesmos documentos, navegador, plataforma de armazenamento e ações do usuário. Os requisitos mínimos do fornecedor são apenas orientações de planejamento, não resultados de desempenho comparáveis.

Este procedimento de referência mede duas coisas distintas: o uso de recursos do servidor e o tempo percebido pelos usuários ao abrir e editar um documento. Ele não afirma que um conjunto de ferramentas seja universalmente mais rápido. Complexidade do arquivo, integração, caminho de rede, fontes e sessões simultâneas podem alterar o resultado.

O que os requisitos publicados podem — e não podem — lhe dizer

Os requisitos atuais do Docker para o ONLYOFFICE listam pelo menos 4 GB de RAM e 4 GB de swap, e sua documentação afirma que os requisitos reais variam de acordo com o número de usuários ativos simultâneos, o tipo e o tamanho do documento. O guia de solução de problemas do Docker indica que o uso de 2 a 4 GB pode ser normal para algumas dezenas de usuários ativos. Essas são observações específicas sobre dimensionamento do ONLYOFFICE e não uma comparação direta com o Collabora.

A Collabora afirma que as necessidades de hardware dependem do número de usuários simultâneos; suas perguntas frequentes também alertam que o desempenho diminui à medida que o uso simultâneo aumenta e depende dos recursos do servidor. O CODE e o produto Collabora Online compatível são opções de implantação distintas. Um pequeno teste doméstico do CODE não prevê uma implantação de assinatura em produção, assim como um teste do ONLYOFFICE Community Edition não representa automaticamente outra edição ou arquitetura. Registre a edição, a versão, o método de implantação e a integração para cada execução.

Em outubro de 2026, o CODE 26.04 era uma versão recente do Collabora. As notas de lançamento descrevem melhorias, incluindo a interoperabilidade de documentos, mas não quantificam o uso de RAM por usuário ou a latência de edição em comparação com o ONLYOFFICE. Considere isso como um motivo para testar as versões atuais e fixadas; não interprete como evidência de uma vantagem de velocidade.

Crie um teste justo e repetível.

1. Use o mesmo host e caminho de integração. Defina os mesmos limites de CPU e memória, local de armazenamento, proxy reverso, configuração TLS e rota de rede para cada conjunto de testes. Se você executar os dois contêineres simultaneamente, eles competirão pelos mesmos recursos; em vez disso, interrompa um dos conjuntos de testes, meça seu desempenho e, em seguida, substitua-o pelo outro. Mantenha o host ocioso.
2. Fixe as versões do software. Registre a tag ou versão exata da imagem, a edição, a versão do Docker, o sistema operacional do host, a versão do navegador e a plataforma conectada. Evite tags flutuantes, como latestdurante uma comparação, pois o software pode mudar entre as versões.
3. Prepare arquivos representativos. Inclua um pequeno documento de texto, uma planilha com fórmulas e gráficos e o arquivo maior ou mais complexo que seus usuários costumam abrir. Use cópias de teste duplicadas, não os originais de produção. Armazene-os na mesma plataforma de documentos usada no trabalho normal.
4. Mantenha as condições do cliente estáveis. Use o mesmo computador, navegador, conexão de rede, tamanho de tela e extensões do navegador. Feche as abas não relacionadas. Para cada teste, certifique-se de que o documento esteja completamente fechado antes de iniciar uma medição de abertura a frio; em seguida, execute testes de abertura a quente separados.
5. Defina os tempos antes de testar. Meça desde a abertura do documento até que ele seja totalmente renderizado e esteja pronto para edição. Para medir a latência de edição, cronometre uma ação específica, como digitar uma frase curta e esperar até que ela apareça para um segundo colaborador. Registre o resultado de cada execução em vez de se basear em uma única impressão.

Meça o uso do servidor e o atraso visível para o usuário.

Memória e CPU

Capture uma linha de base ociosa após o serviço estabilizar. Em seguida, registre o uso de memória e CPU do contêiner enquanto abre um arquivo, o edita e o mantém aberto. Repita o processo com vários documentos e usuários simultâneos, em níveis que correspondam à sua carga de trabalho esperada. Para o Docker, docker stats --no-streamo comando `docker-compose up` exibe um instantâneo dos recursos em um determinado momento; use-o repetidamente durante cada fase ou colete uma série temporal com seu sistema de monitoramento existente. Registre também a memória disponível no nível do host, pois o uso relatado por um contêiner, por si só, não mostra se toda a máquina está sob pressão.

Relate o pico de memória, a memória média durante a fase ativa e a memória ociosa após o fechamento dos documentos. Mantenha o mesmo intervalo de amostragem. Não considere a memória utilizada após um documento como equivalente à capacidade de uma equipe: sessões, tamanho do arquivo, complexidade de renderização e edição simultânea são fatores importantes. Se a implementação suportar métricas do Prometheus, colete-as de forma consistente; a documentação da Collabora apresenta métricas compatíveis com o Prometheus e monitoramento de sessões em tempo real. Para o ONLYOFFICE, utilize os diagnósticos de contêiner e as orientações de recursos documentadas. Evite comparar a métrica de processo interna de um produto com o total de todo o contêiner de outro produto.

Latência de abertura e edição

Execute pelo menos cinco inicializações a frio e cinco inicializações a quente para cada arquivo representativo. Relate o tempo mediano e o tempo mais lento observado, não apenas o melhor resultado. Uma inicialização a frio inclui tarefas como carregar o documento e renderizar sua visualização inicial; uma inicialização a quente pode se beneficiar de caches. Use a mesma definição de "pronto" em ambos os editores.

Para medir o atraso na colaboração, conecte duas sessões do navegador e meça o tempo decorrido entre uma edição específica em uma sessão e a atualização visível na outra. Repita a mesma ação várias vezes, tanto sem outros documentos abertos quanto sob a carga simultânea pretendida. Isso captura o efeito combinado do editor, do servidor, da integração de armazenamento e da rede. Se o navegador e o servidor estiverem em redes diferentes, registre as condições de ida e volta; o atraso da rede pode ser mais significativo do que o próprio processamento do editor.

Leia os resultados sem exagerar nas expectativas.

Escolha o pacote que atenda à sua meta de latência, mantendo memória e CPU suficientes para uma concorrência realista. Se os resultados forem próximos, priorize a compatibilidade de documentos, o suporte à integração, a familiaridade operacional e o licenciamento. Execute o mesmo teste novamente após uma grande atualização ou alteração na infraestrutura. Para obter detalhes específicos da versão, consulte as notas de versão do CODE 26.04 da Collabora , as perguntas frequentes e a visão geral de segurança e monitoramento do Collabora Online , além dos requisitos do Docker da Community Edition da ONLYOFFICE e as orientações de solução de problemas e recursos do Docker . Essas fontes descrevem cada produto separadamente; não se trata de um teste comparativo direto e controlado.