В релизе CODE 26.04 от Collabora Online, анонсированном 8 июня 2026 года, представлены изменения, касающиеся совместимости документов и удобства использования, однако в примечаниях к релизу не опубликовано контролируемое сравнение оперативной памяти и задержки с ONLYOFFICE Docs. Для принятия обоснованного решения проведите сравнительный анализ производительности именно тех сборок, которые вы планируете развернуть на том же хосте, с теми же документами, браузером, платформой хранения и действиями пользователей. Минимальные требования поставщика являются рекомендациями по планированию, а не сравнительными результатами производительности.
Данная эталонная процедура измеряет два отдельных параметра: использование ресурсов сервера и время, которое пользователи ощущают при открытии и редактировании документа. Она не утверждает, что какой-либо один набор инструментов является универсально более быстрым. Сложность файлов, интеграция, сетевой путь, шрифты и количество одновременно работающих сессий могут повлиять на результат.
Что могут — и чего не могут — сообщить вам опубликованные требования
В текущих требованиях ONLYOFFICE к Docker указано как минимум 4 ГБ оперативной памяти и 4 ГБ файла подкачки, а в документации говорится, что фактические требования варьируются в зависимости от количества одновременно активных пользователей, типа и размера документов. В руководстве по устранению неполадок Docker указано, что использование 2–4 ГБ может быть нормой для нескольких десятков активных пользователей. Это рекомендации по размерам, специфичные для ONLYOFFICE, а не прямое сравнение с Collabora.
Компания Collabora заявляет, что потребности в оборудовании зависят от количества одновременно работающих пользователей; в разделе часто задаваемых вопросов также указывается, что производительность снижается по мере роста количества одновременных пользователей и зависит от ресурсов сервера. CODE и поддерживаемый продукт Collabora Online — это разные варианты развертывания. Небольшой домашний тест CODE не предсказывает развертывание по производственной подписке, так же как тест ONLYOFFICE Community Edition не автоматически представляет другую версию или архитектуру. Записывайте версию, релиз, метод развертывания и интеграцию для каждого запуска.
По состоянию на октябрь 2026 года, CODE 26.04 — это недавний релиз Collabora. В примечаниях к релизу описываются улучшения, включая совместимость документов, но не приводятся данные о объеме оперативной памяти на пользователя или задержке редактирования по сравнению с ONLYOFFICE. Воспринимайте это как повод протестировать текущие, закрепленные сборки; не рассматривайте это как доказательство преимущества в скорости.
Создайте справедливый и воспроизводимый тест.
- Используйте один и тот же хост и путь интеграции. Установите для каждого набора тестов одинаковые ограничения по ЦП и памяти, место хранения, обратный прокси, настройку TLS и сетевой маршрут. Если вы запустите оба контейнера одновременно, они будут конкурировать за одни и те же ресурсы; вместо этого остановите один набор тестов, измерьте его производительность, а затем замените другим. В остальное время хост должен оставаться в режиме ожидания.
- Зафиксируйте версии программного обеспечения. Запишите точный тег образа или релиза, редакцию, версию Docker, операционную систему хоста, версию браузера и подключенную платформу. Избегайте плавающих тегов, например,
latestпри сравнении, поскольку программное обеспечение может меняться между испытаниями. - Подготовьте репрезентативные файлы. Включите небольшой текстовый документ, электронную таблицу с формулами и диаграммами, а также самый большой или наиболее сложный файл, который обычно открывают ваши пользователи. Используйте дубликаты тестовых копий, а не оригинальные файлы для производственной среды. Храните их на той же платформе для работы с документами, что и в обычной работе.
- Сохраняйте стабильные условия для клиента. Используйте один и тот же компьютер, браузер, сетевое соединение, размер экрана и расширения браузера. Закрывайте несвязанные вкладки. Для каждого испытания убедитесь, что документ полностью закрыт, прежде чем начинать измерение с «холодным» открытием; затем проведите отдельные испытания с «теплым» открытием.
- Определите временные параметры перед тестированием. Измеряйте время от момента открытия документа до его полной отрисовки и возможности редактирования. Для измерения задержки редактирования засеките время для определенного действия, например, набора короткой фразы и ожидания ее появления у второго участника. Записывайте результаты каждого запуска, а не полагайтесь на один показ.
Измерьте загрузку сервера и задержку, видимую пользователю.
Память и ЦП
Зафиксируйте базовый уровень простоя после стабилизации работы сервиса. Затем запишите объем памяти и загрузку ЦП контейнера, открыв один файл, отредактировав его и оставив открытым. Повторите то же самое с несколькими одновременно работающими документами и пользователями на уровнях, соответствующих ожидаемой рабочей нагрузке. Для Docker docker stats --no-streamотображается моментальный снимок ресурсов на определенный момент времени; используйте его многократно на каждом этапе или соберите временной ряд с помощью существующей системы мониторинга. Запишите также доступную память на уровне хоста, поскольку сообщаемое использование контейнером само по себе не показывает, находится ли вся машина под нагрузкой.
Сообщайте о пиковом объеме используемого памяти, среднем объеме памяти во время активной фазы и объеме неиспользуемой памяти после закрытия документов. Сохраняйте тот же интервал выборки. Не приравнивайте объем памяти после одного документа к емкости для всей команды: важны сессии, размер файла, сложность рендеринга и одновременное редактирование. Если развертывание поддерживает метрики Prometheus, собирайте их последовательно; Collabora документирует метрики, совместимые с Prometheus, и мониторинг сессий в реальном времени. Для ONLYOFFICE используйте документированные средства диагностики контейнеров и рекомендации по ресурсам. Избегайте сравнения внутренних метрик процесса одного продукта с общим объемом памяти всего контейнера другого продукта.
Откройте и отредактируйте задержку.
Для каждого репрезентативного файла выполните не менее пяти холодных и пяти теплых открытий. Сообщите медианное и самое медленное наблюдаемое время, а не только лучший результат. Холодное открытие включает в себя такие действия, как загрузка документа и рендеринг его начального вида; теплое открытие может быть выгодно при использовании кэша. Используйте одно и то же определение «готовности» в обоих редакторах.
Для измерения задержки при совместной работе подключите две сессии браузера и измерьте время от внесения конкретного изменения в одной сессии до видимого обновления в другой. Повторите это действие несколько раз, при этом ни один документ не должен быть открыт, а нагрузка будет соответствовать требуемой. Это позволит зафиксировать совокупное воздействие редактора, сервера, интеграции хранилища и сети. Если браузер и сервер находятся в разных сетях, запишите параметры передачи данных; задержка в сети может преобладать над обработкой данных самим редактором.
Ознакомьтесь с результатами, не делая поспешных выводов.
| Наблюдаемый шаблон | Вероятная интерпретация | Следующая проверка |
|---|
| Большой объем оперативной памяти в режиме ожидания | В качестве базового показателя могут использоваться службы, запускающиеся при старте системы, или кэшированные сессии; продукты могут по-разному очищать неиспользуемые документы. | Проведите измерения после заданного интервала простоя и сравните объем памяти хоста и память контейнера. |
| Быстрое открытие, медленное редактирование под нагрузкой. | При редактировании или совместной работе могут быть ограничения, связанные с производительностью процессора, функциями обратного вызова хранилища или сетью. | Повторите процедуру с меньшим количеством параллельных запросов и одновременно проверьте работу процессора, диска и сети. |
| Медленно работает только один файл. | Ограничивающим фактором может быть структура файла, формулы, встроенные объекты или шрифты. | Протестируйте другой файл аналогичного размера, а затем изучите специфические особенности проблемного файла. |
| Холодные входные отверстия различаются, теплые — нет. | Значительная часть расхождения может быть объяснена особенностями инициализации или поведением кэша. | Результаты, полученные при низких и высоких температурах, следует рассматривать отдельно; не следует усреднять их. |
Выберите набор тестов, который соответствует вашим целевым показателям задержки, оставляя при этом достаточный запас памяти и ресурсов ЦП при реалистичной параллельной обработке. Если результаты близки, отдайте приоритет совместимости документов, поддержке интеграции, знакомству с операционной системой и лицензированию. Повторите тот же тест после крупного обновления или изменения инфраструктуры. Для получения подробной информации по конкретным версиям см. примечания к выпуску CODE 26.04 от Collabora , часто задаваемые вопросы и обзор безопасности и мониторинга Collabora Online , а также требования к Docker для ONLYOFFICE Community Edition и руководство по устранению неполадок и ресурсам Docker . Эти источники описывают каждый продукт отдельно; они не являются контролируемым сравнительным тестом.