Кластер из трёх узлов обслуживает 550–600 вызовов API в секунду на корпусе в 1,05 млн документов. До 500 вызовов в секунду 95 % ответов приходят быстрее 0,22 с. Ниже — как мерили, что получилось, сравнение с Nuxeo и границы, за которыми эти числа не действуют.
Замеры Руксео — 23–24 сентября 2026 года, версия 2025.20.0-ruxeo.1, сборка от 23.09.2026. Замеры Nuxeo для сравнения — 30–31 августа 2026 года на платформе 2025.19.
вызовов API в секунду держит кластер из трёх узлов. До 500 вызовов p95 не выше 0,22 с.
вызовов в секунду держит один узел. Его предел — процессор: 89 % на 400 вызовах.
даёт переход с одного узла на три. Процессорная стоимость вызова на кластере выше на 5–15 %.
больше процессорного времени тратит Руксео на ту же работу, чем платформа Nuxeo без прикладного слоя.
Нагрузка подаётся ступенями по 100 вызовов в секунду. Три узла проходят ступени 300–500 с p95 от 0,15 до 0,22 с. На 600 кластер обрабатывает 96 % поданного, и p95 вырастает до 1,9 с. На 700 обработано 81 %: это предел.
Секунды, логарифмическая шкала. Линия — медиана трёх прогонов, точки — отдельные прогоны.
Вызовов API в секунду. Пунктир — обработано всё, что подано.
| Узлов | Подано, вызовов/с | Обработано, вызовов/с | p50, мс | p95, мс | p99, мс | CPU узлов, % | CPU базы, % | CPU индекса, % | Отказов |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 200 | 200 | 35 | 158 | 244 | 44 | 7 | 8 | 0 |
| 1 | 300 | 299 | 42 | 184 | 316 | 63 | 13 | 13 | 0 |
| 1 | 400 | 399 | 67 | 301 | 414 | 80 | 19 | 17 | 0 |
| 3 | 300 | 299 | 35 | 149 | 173 | 23 | 12 | 13 | 0 |
| 3 | 400 | 399 | 37 | 163 | 247 | 31 | 17 | 18 | 0 |
| 3 | 500 | 499 | 43 | 215 | 352 | 42 | 23 | 24 | 0 |
| 3 | 600 | 578 | 1 138 | 1 872 | 2 281 | 60 | 36 | 38 | 0 |
| 3 | 700 | 570 | 5 513 | 7 568 | 8 014 | 60 | 35 | 43 | 0 |
Медианы трёх прогонов по окну устоявшейся нагрузки. CPU — средняя загрузка машины за то же окно; для трёх узлов — среднее по узлам. Один узел на 400 вызовах в пике загружен на 89 %.
Три узла, 500 вызовов в секунду — рабочая точка кластера. Медианы трёх прогонов.
| Операция | p50, мс | p95, мс |
|---|---|---|
| Полнотекстовый поиск по метаданным, около 100 совпадений | 184 | 271 |
| Полнотекстовый поиск по содержимому вложений, около 100 совпадений | 186 | 253 |
| Полнотекстовый поиск по групповому признаку, около 10 000 совпадений | 154 | 235 |
| Атрибутивный поиск по полям карточки | 171 | 234 |
| Список документов папки | 140 | 204 |
| Создание документа | 40 | 61 |
| Переход к родительской папке | 17 | 40 |
| Скачивание вложения | 15 | 25 |
| Просмотр карточки документа | 14 | 19 |
| Выдача токена | 5 | 7 |
Руксео построен на платформе Nuxeo. Замер Nuxeo на том же стенде, корпусе того же объёма и тех же сценариях показывает, во что обходится прикладной слой Руксео.
| Показатель | Nuxeo | Руксео | Отношение |
|---|---|---|---|
| Процессор узла на один цикл из 10 вызовов, % | 0,90 | 2,0–2,2 | ×2,2–2,5 |
| Ёмкость трёх узлов, вызовов/с | 1 100 | 550–600 | ×0,5–0,55 |
| p95 на трёх узлах при 300 вызовах/с, мс | 61 | 149 | ×2,4 |
| Загрузка узлов при 300 вызовах/с, % | 11–12 | 23 | ×2 |
| Ёмкость одного узла, вызовов/с | 800 | 350–400 | ×0,45–0,5 |
Три узла в обоих замерах работали в одинаковой конфигурации.
Это оценка, приводим всю сетку и формулу. Рабочую точку берём ниже ёмкости, с запасом на пики: 500 вызовов в секунду для трёх узлов, 300 для одного.
| Действий в час на пользователя | 10 вызовов на действие | 20 вызовов | 40 вызовов |
|---|---|---|---|
| 20 | 9 000 | 4 500 | 2 250 |
| 40 | 4 500 | 2 250 | 1 125 |
| 60 | 3 000 | 1 500 | 750 |
Три узла, 500 вызовов в секунду. Для одного узла умножьте на 0,6: центральная оценка — 1 350 пользователей. Центральная оценка — 40 действий в час, то есть одно действие в полторы минуты, и 20 вызовов API на действие.
От 750 до 9 000 пользователей на одних и тех же трёх узлах. Весь разброс — в двух множителях: сколько действий в час совершает сотрудник и сколько вызовов API стоит одно действие в интерфейсе.
Нужны три числа вашего проекта: доли операций, действий в час на активного сотрудника и отношение пикового часа к среднему. С ними профиль прогоняется на стенде так же, как описано ниже.
Выдача токена, создание документа, просмотр карточки, скачивание вложения, список папки, переход к родительской папке, атрибутивный поиск и три полнотекстовых поиска. По одному вызову каждого вида, доли равные. Пять учётных записей, одна из них — администратор.
1 000 000 входящих документов с заполненными реквизитами и 50 000 с вложениями, в 2 001 папке. Узкий поисковый признак находит около 100 документов, групповой — около 10 000. Перед замерами корпус и поисковый индекс проверены на полноту.
Ступени по 100 вызовов в секунду. Разгон 60 с, затем 240 с устоявшейся нагрузки, первые 30 с не учитываются. Три прогона на ступень, в зачёт медиана. Между прогонами созданные документы удаляются, очереди индексации разбираются. Первый прогон после перезапуска узлов в результаты не входит. Генератор нагрузки загружен не выше чем на 13 %.
Медиана p95 выше 2 с, отказов больше 1 % или процессор узла выше 85 %. Ёмкость — диапазон между последней ступенью с фоновой задержкой и ступенью, где система выходит на предел.
На первом хосте только узлы платформы и база. Поисковый индекс и брокер сообщений стоят на втором, остальные служебные машины вынесены с первого. Генератор нагрузки работает вне обоих хостов.
| Роль | Машина | Программное обеспечение |
|---|---|---|
| Хост 1 | AMD EPYC 7K62, 48 ядер / 96 потоков, 320 ГБ | Proxmox VE 9 |
| Хост 2 | 2 × Intel Xeon E5-2696 v4, 44 ядра / 88 потоков, 196 ГБ | Proxmox VE 9 |
| Сеть между хостами | 1 Гбит/с | |
| Узлы платформы, 3 шт., хост 1 | 16 vCPU, 48 ГБ, куча JVM 24 ГБ | Руксео 2025.20.0-ruxeo.1, Nuxeo 2025.20, JDK 21, Debian 13; 50 потоков на узел |
| База данных, хост 1 | 32 vCPU, 64 ГБ | PostgreSQL 16, shared_buffers 16 ГБ |
| Поисковый индекс, хост 2 | 48 vCPU, 64 ГБ, куча 16 ГБ | OpenSearch 2.19, один узел |
| Брокер сообщений, хост 2 | 4 vCPU, 8 ГБ | Apache Kafka 3.9 |
| Балансировщик | 4 vCPU, 4 ГБ | HAProxy 3.0 |
| Файловое хранилище | 4 vCPU, 8 ГБ | NFS |
| Генератор нагрузки | 8 vCPU, вне хостов | Gatling 3.11, JDK 21 |
Каждый десятый вызов создаёт документ: на 500 вызовах в секунду это 180 000 документов в час. Поиск занимает 40 % вызовов, доступ к документам равномерный, правок, версий и маршрутов нет. Смещения разнонаправлены, поэтому поправочного коэффициента не существует.
Всё снято на 1,05 млн документов, и рабочий набор целиком помещался в память базы: 99,99 % чтений из буфера. По нашей оценке, на этом стенде так будет до 2,5–3 млн документов. Что будет дальше, не измерено.
Пришлите число сотрудников, основные сценарии и пиковые часы. Разберём, какая конфигурация нужна, и где оценку стоит заменить замером.