Если при совместном редактировании в ONLYOFFICE на собственном сервере Docker наблюдается замедление работы, сначала определите, связана ли задержка с сервером, сетевым путем или конкретным документом. Измерьте производительность той же сессии редактирования, прежде чем что-либо менять: проверьте использование ресурсов контейнера и хоста, затем убедитесь, что ваш обратный прокси-сервер корректно передает соединение с редактором в режиме реального времени. Добавляйте ресурсы ЦП, памяти или дополнительную инфраструктуру только тогда, когда измерения покажут ограничение пропускной способности.
Попросите двух редакторов открыть один и тот же документ и одновременно внести небольшое изменение. Обратите внимание, наблюдается ли задержка при наборе текста у обоих пользователей, видят ли обновления один из пользователей с задержкой и возникает ли проблема со всеми файлами или только с одним большим или сложным файлом. Это простое сравнение помогает отделить общую проблему сервиса от проблемы, специфичной для конкретного документа.
На хосте Docker найдите контейнер Document Server и понаблюдайте за использованием им ресурсов во время возникновения задержки:
docker ps
docker stats <container_name_or_id>Обратите внимание на устойчивую загрузку ЦП, приближение объема памяти к пределу хоста или контейнера, активность файла подкачки или перезапуск контейнера. Также проверьте дисковое пространство хоста и операции ввода-вывода, если сохранение или загрузка документов приостанавливаются. Кратковременный всплеск менее показателен, чем узкое место, совпадающее с медленным редактированием. На странице устранения неполадок ONLYOFFICE Docker отмечается, что использование памяти возрастает с открытием документов и количеством одновременно работающих пользователей; в качестве нормы для сервера с несколькими десятками активных пользователей указывается 2–4 ГБ, но это не является универсальной гарантией оптимального размера.
Помните, что ONLYOFFICE считает одновременно активного пользователя тем, у кого открыт документ, независимо от того, редактирует он или просматривает. Сравните максимальное количество открытых редакторов с системными требованиями Community Docker для конкретной версии . Опубликованные данные представляют собой эталонные конфигурации, а в документации указано, что фактическая производительность зависит от типа и размера документа.
Если редактор загружается, но соредакторы постоянно отключаются, или задержка наблюдается только через ваш публичный URL, проверьте обратный прокси-сервер, прежде чем добавлять ресурсы сервера. WebSocket — это постоянное соединение, используемое для передачи данных от редактора в режиме реального времени. Прокси-сервер, который закрывает или не может обновить это соединение, может привести к задержке редактирования или к повторным подключениям.
Проверьте журналы доступа и ошибок прокси-сервера во время одной из задержек. Убедитесь, что ваша конфигурация пересылает заголовки HTTP Upgrade и Connection и сохраняет исходный хост и протокол. Для NGINX сравните свою настройку с официальными примерами прокси-сервера ONLYOFFICE ; в документации специально упоминаются пересылаемые X-Forwarded-Protoзаголовки X-Forwarded-Host. Не копируйте пример целиком, если ваше завершение TLS, префикс пути или топология прокси-сервера отличаются.
Также проведите тестирование с клиента в той же локальной сети и с обычного удаленного маршрута. Если сеанс в локальной сети работает быстро, а публичный маршрут работает медленно, проверьте задержку прокси-сервера, брандмауэра, VPN, DNS или WAN. Если задержки наблюдаются на обоих маршрутах одновременно, более вероятной причиной является перегрузка на стороне сервера. Инструменты разработчика в браузере могут помочь: повторяющиеся разрывы соединения WebSocket указывают на проблемы с обработкой соединения, в то время как стабильное соединение с медленным редактированием на перегруженном хосте указывает на проблемы с пропускной способностью или рабочей нагрузкой.
ONLYOFFICE предлагает режим быстрого совместного редактирования, который является настройкой по умолчанию и отображает изменения других пользователей в режиме реального времени, и режим строгого совместного редактирования, который сохраняет изменения до тех пор, пока пользователь их не сохранит. В документации по совместному редактированию описана разница в способах отображения изменений. Строгий режим подходит для команд, которые предпочитают просматривать и применять изменения партиями; быстрый режим — это естественный выбор, когда важна немедленная видимость изменений для всех пользователей.
Смена режимов не устраняет перегрузку процессора, ограничение объема памяти или неисправность маршрута WebSocket. Рассматривайте режим как параметр для совместной работы, а сравнение количества файлов и пользователей в каждом режиме следует проводить только в том случае, если ваша команда решает, какой рабочий процесс подходит лучше. Избегайте представления переключения режимов как гарантированного повышения производительности.
Если наблюдаются задержки при работе с документами и пользователями, при этом процессор остается перегруженным, память ограничена или контейнеры перезапускаются, сначала выделите Document Server достаточные ресурсы хоста и убедитесь, что ограничения Docker не превышают возможности хоста. Затем проведите повторное тестирование. В опубликованном справочнике Docker Community Edition указаны требования к оперативной памяти и хранилищу объемом 4 ГБ, которые варьируются в зависимости от количества одновременно работающих пользователей; для более чем 400 активных пользователей рекомендуется развертывание кластера и указание на Kubernetes. Используйте эти данные в качестве ориентира для планирования, а не как гарантию того, что данный сервер будет поддерживать конкретную рабочую нагрузку.
Для небольших установок увеличение доступного процессора или памяти обычно проще, чем разделение служб между хостами. При стабильно высокой параллельности отдельные или кластерные службы могут обеспечить больший запас производительности, но они добавляют сетевые зависимости, конфигурацию, мониторинг и точки отказа. В текущем официальном примере Compose от ONLYOFFICE включена проверка работоспособности конечной точки Document Server; используйте показатели работоспособности контейнера и отзывчивости приложения вместе, а не предполагайте, что работающий контейнер означает бесперебойную работу редактирования. Поддерживайте фиксированную версию образа во время диагностики, чтобы обновление развертывания не искажало результаты измерений до и после.
Повторите исходное редактирование двумя пользователями, используя тот же документ, маршрут клиента и приблизительную нагрузку. Убедитесь, что ввод текста происходит быстро обоими редакторами, изменения отображаются стабильно в выбранном режиме совместного редактирования, а переподключения или перезапуски контейнеров прекратились. docker statsВо время повторного тестирования понаблюдайте за процессом и проверьте журналы прокси-сервера, если проблема связана с подключением. Если небольшой тест прошел успешно, но в часы пик по-прежнему наблюдаются задержки, соберите образ/версию контейнера, версии хоста и Docker, смонтированные тома, графики ресурсов и соответствующие журналы, прежде чем изменять дополнительные настройки; в официальном руководстве по отладочному логированию объясняется, как включить временные отладочные журналы в Docker. После сбора данных уменьшите уровень детализации логирования, поскольку это увеличивает объем логов.
Используйте полученные результаты для выбора компромиссного решения: корректируйте работу прокси-сервера при разрыве соединений, увеличивайте пропускную способность, когда измерения показывают устойчивое давление на ресурсы, и оставляйте сервер в покое, если затронут только один сложный документ, пока не будет локализована эта рабочая нагрузка.
Определите, использует ли Document Server пакет Linux или Docker, удалите только его компоненты и проверьте оставшиеся данные, не удаляя по ошибке общие службы.
Причину замедления совместного редактирования можно определить как нехватку ресурсов Docker, проблемы с прокси-соединениями или загрузку документов, после чего выберите решение, соответствующее вашим измерениям.
Выберите место завершения TLS-соединения, безопасно смонтируйте доверенный сертификат и закрытый ключ, а также проверьте доступ по HTTPS к серверу ONLYOFFICE Docs, работающему в контейнере Docker.
Встройте редактор ONLYOFFICE в свое PHP-приложение, подпишите его конфигурацию с помощью JWT и сохраняйте отредактированные файлы через защищенный обратный вызов.
Установите язык проверки орфографии для всего документа или выделенного текста, убедитесь, что проверка орфографии активна, и определите, когда отсутствует словарь сервера.
Включите функцию отслеживания изменений для всех пользователей в одном документе ONLYOFFICE, убедитесь, что внесенные изменения записываются, и ознакомьтесь с ограничениями этой настройки.
Выясните, возвращает ли Nginx, сетевые компоненты Docker или внутренний сервис ONLYOFFICE ошибку 502, затем проверьте исправленные данные в вышестоящем сервере и результаты проверки работоспособности.
Для диагностики сбоев сохранения файлов в ONLYOFFICE проверьте маршрут обратного вызова Nextcloud, перенаправления прокси-сервера и журналы хранилища, а затем убедитесь, что отредактированный файл сохраняется.
Найдите причину сбоев памяти в ONLYOFFICE, проверьте ограничения Docker, правильно определите размер оперативной памяти VPS, безопасно добавьте файл подкачки и убедитесь, что документы открываются и сохраняются.
Отделите проблемы с загрузкой из браузера от ошибок преобразования на стороне сервера и используйте правильную проверку журнала или доступа, чтобы экспорт в PDF работал корректно.
