Quando a edição colaborativa do ONLYOFFICE parecer lenta em um servidor Docker autohospedado, primeiro determine se o atraso está relacionado ao servidor, ao caminho da rede ou a um documento específico. Meça a mesma sessão de edição antes de fazer qualquer alteração: verifique o uso de recursos do contêiner e do host e confirme se o seu proxy reverso está encaminhando corretamente a conexão do editor em tempo real. Adicione CPU, memória ou mais infraestrutura somente quando essas medições indicarem um limite de capacidade.
Peça a dois editores que abram o mesmo documento e façam uma pequena alteração simultaneamente. Observe se há atraso na digitação para ambos os usuários, se um deles vê as atualizações com atraso e se o problema ocorre com todos os arquivos ou apenas com um arquivo grande ou complexo. Essa comparação simples ajuda a diferenciar um problema geral do serviço de uma carga de trabalho específica do documento.
No host Docker, identifique o contêiner do Servidor de Documentos e observe o uso de recursos enquanto ocorre a lentidão:
docker ps
docker stats <container_name_or_id>Procure por saturação sustentada da CPU, memória se aproximando do limite do host ou do contêiner, atividade de swap ou um contêiner reiniciando. Verifique também o espaço em disco do host e as operações de E/S caso haja pausas nos salvamentos ou no carregamento de documentos. Um pico curto é menos conclusivo do que um gargalo que coincida com as edições lentas. A página de solução de problemas do Docker da ONLYOFFICE observa que o uso de memória aumenta com documentos abertos e usuários simultâneos; ela indica 2 a 4 GB como normal para um servidor com algumas dezenas de usuários ativos, mas esse não é um valor universal garantido.
Lembre-se de que o ONLYOFFICE considera um usuário ativo simultâneo como aquele que tem um documento aberto, seja editando ou visualizando. Compare o seu pico de usuários com editores abertos com os requisitos de sistema do Docker da comunidade específicos para a sua edição . Os valores publicados são configurações de referência e a documentação indica que a capacidade real depende do tipo e tamanho do documento.
Se o editor carregar, mas os coeditores se desconectarem repetidamente, ou se o atraso aparecer apenas no seu URL público, verifique o proxy reverso antes de adicionar recursos ao servidor. O WebSocket é a conexão persistente usada para o tráfego do editor em tempo real. Um proxy que fecha ou não atualiza essa conexão pode fazer com que as edições pareçam atrasadas ou causar reconexões.
Verifique os logs de acesso e erro do proxy durante uma sessão com lentidão. Confirme se sua configuração encaminha os cabeçalhos HTTP Upgrade e Connection e preserva o host e o protocolo originais. Para NGINX, compare sua configuração com os exemplos oficiais de proxy da ONLYOFFICE ; a documentação menciona especificamente os cabeçalhos encaminhados X-Forwarded-Proto. X-Forwarded-HostNão copie e cole um exemplo integralmente se a sua terminação TLS, prefixo de caminho ou topologia de proxy forem diferentes.
Teste também a partir de um cliente na mesma LAN e da rota remota normal. Se a sessão na LAN responder bem, enquanto a rota pública estiver lenta, investigue o proxy, o firewall, a VPN, o DNS ou a latência da WAN. Se ambas as rotas apresentarem lentidão simultaneamente, a sobrecarga no servidor torna-se mais provável. As ferramentas de desenvolvedor do navegador podem ajudar: desconexões repetidas do WebSocket indicam problemas no gerenciamento da conexão, enquanto uma conexão estável com edição lenta em um host saturado aponta para problemas de capacidade ou carga de trabalho.
O ONLYOFFICE oferece a edição colaborativa Rápida, que é a padrão e exibe as edições de outros usuários em tempo real, e a edição colaborativa Estrita, que retém as alterações até que um usuário as salve. A documentação da edição colaborativa descreve a diferença na forma como as alterações são exibidas. A edição Estrita é ideal para equipes que preferem revisar e aplicar alterações em lotes; a edição Rápida é a escolha natural quando a visibilidade compartilhada imediata é essencial.
A mudança de modo não resolve problemas como CPU saturada, limite de memória insuficiente ou rota WebSocket interrompida. Considere o modo como uma preferência de colaboração e compare o mesmo número de arquivos e usuários em cada modo somente se a sua equipe estiver decidindo qual fluxo de trabalho é o mais adequado. Evite apresentar a mudança de modo como uma garantia de melhoria de desempenho.
Se ocorrer lentidão entre documentos e usuários enquanto a CPU permanece saturada, a memória está limitada ou os contêineres são reiniciados, primeiro aloque recursos adequados ao Document Server no host e verifique se os limites do Docker não comprometem a capacidade do host. Em seguida, teste novamente. A documentação de referência do Docker Community Edition lista 4 GB de RAM e requisitos de armazenamento que variam de acordo com o número de usuários simultâneos; para mais de 400 usuários ativos simultâneos, recomenda-se a implantação em cluster e o uso do Kubernetes. Use esses valores como referência para planejamento, não como garantia de que um determinado servidor suportará uma carga de trabalho específica.
Para instalações pequenas, aumentar a CPU ou a memória disponível geralmente é mais simples do que dividir os serviços entre vários hosts. Para alta concorrência sustentada, serviços separados ou em cluster podem oferecer mais margem de segurança, mas adicionam dependências de rede, configuração, monitoramento e pontos de falha. O exemplo oficial atual do Compose da ONLYOFFICE inclui uma verificação de integridade para o endpoint do Servidor de Documentos; use a integridade do contêiner e a capacidade de resposta do aplicativo em conjunto, em vez de presumir que um contêiner em execução significa um caminho de edição saudável. Mantenha a versão da imagem fixa durante o diagnóstico para que uma atualização de implantação não interfira nas medições de antes e depois.
Repita a edição original com dois usuários usando o mesmo documento, rota do cliente e carga aproximada. Confirme se a digitação está responsiva para ambos os editores, se as alterações aparecem de forma consistente no modo de coedição selecionado e se as reconexões ou reinicializações do contêiner cessaram. Observe docker statsdurante o novo teste e verifique os logs do proxy se o problema estava relacionado à conexão. Se um pequeno teste funcionar, mas as sessões em horários de pico ainda apresentarem lentidão, colete a imagem/versão do contêiner, as versões do host e do Docker, os volumes montados, os gráficos de recursos e os logs relevantes antes de alterar mais configurações; o guia oficial de logs de depuração explica como habilitar logs de depuração temporários no Docker. Reduza o nível de detalhamento dos logs após coletar as evidências, pois isso aumenta o volume de logs.
Use o resultado para escolher a melhor estratégia: corrija o proxy quando as conexões forem interrompidas, adicione capacidade quando as medições mostrarem pressão constante nos recursos e deixe o servidor em paz quando apenas um documento complexo for afetado, até que você tenha isolado essa carga de trabalho.
Identifique a causa da lentidão na edição colaborativa devido à pressão sobre os recursos do Docker, conexões proxy ou carga de documentos e, em seguida, escolha a solução que corresponda às suas medições.
Escolha onde o TLS deve ser encerrado, monte um certificado confiável e uma chave privada com segurança e verifique o acesso HTTPS a um servidor ONLYOFFICE Docs em um contêiner Docker.
Incorpore o editor ONLYOFFICE em seu aplicativo PHP, assine sua configuração com JWT e salve os arquivos editados por meio de um retorno de chamada seguro.
Defina o idioma de verificação ortográfica para todo o documento ou para o texto selecionado, confirme se a verificação ortográfica está ativa e identifique quando um dicionário do servidor estiver faltando.
Ative o recurso de controle de alterações persistente para todos em um documento do ONLYOFFICE, verifique se as edições foram registradas e compreenda as limitações dessa configuração.
Verifique se o Nginx, a rede Docker ou um serviço interno do ONLYOFFICE está retornando o erro 502 e, em seguida, confirme o upstream corrigido e realize a verificação de integridade.
Diagnostique falhas ao salvar no ONLYOFFICE verificando a rota de retorno de chamada do Nextcloud, redirecionamentos de proxy e logs de armazenamento e, em seguida, verifique se o arquivo editado persiste.
Identifique a causa das falhas de memória do ONLYOFFICE, verifique os limites do Docker, dimensione corretamente a RAM do VPS, adicione swap com segurança e verifique se os documentos abrem e são salvos corretamente.
Separe os problemas de download do navegador dos erros de conversão do lado do servidor e use o registro correto ou a verificação de acesso para que a exportação para PDF funcione.
Combine o segredo JWT usado pelo ONLYOFFICE Docs e Nextcloud, aplique-o com segurança em instalações Docker ou Linux e verifique a conexão sem enfraquecer a autenticação.
