umbot
    Preparing search index...

    Производительность: чего ожидать и когда волноваться

    umbot спроектирована с прицелом на высокую производительность и предсказуемое время отклика. Это особенно важно, учитывая жёсткие ограничения по времени от платформ (например, 3 секунды для Яндекс.Диалогов).

    Этот документ описывает:

    • сколько времени тратит сам фреймворк на обработку запроса,
    • в каких сценариях могут возникнуть задержки,
    • как её производительность соотносится с решениями, заточенными под одну платформу.

    Все данные получены в контролируемых условиях и воспроизводимы — вы можете запустить тесты самостоятельно.

    В типичных сценариях (до 1 000 команд) внутренняя обработка umbot занимает менее 30 мс для холодного запуска. Это включает:

    • парсинг входящего запроса,
    • определение нужной платформы
    • чтение/запись пользовательских данных,
    • поиск подходящей команды,
    • формирование ответа.
    1. Первичная загрузка медиафайлов
      При первом использовании изображения или аудиофайла фреймворк загружает его на сервер платформы и кэширует токен. Эта операция может занять от 200 мс до 1+ секунды, в зависимости от размера файла и загрузки серверов платформы.
      → Решение: предварительно загрузить ресурсы через Preload.

    2. Холодный запуск с большим числом сложных регулярных выражений
      При первом вызове с 10 000+ непрокэшированных регулярок время может достичь 200–500 мс.
      → Решение: использовать re2, проверять регексы на ReDoS, прогревать кэш при старте.

    ⚠️ Важно: время выполнения пользовательской логики (ваш код в addCommand или action) не входит в эти цифры. Если ваш обработчик работает 2.5 сек — это ваша зона ответственности.


    umbot — это мультиплатформенный фреймворк, тогда как Telegraf, vk-io, alice-kit и т.д. — специализированные SDK.

    Прямое сравнение производительности некорректно по нескольким причинам:

    1. Разные архитектурные задачи — специализированные библиотеки фокусируются на глубокой интеграции с одной платформой (например, опросы в Telegram), тогда как umbot обеспечивает единый API для всех платформ
    2. Разные точки замера — бенчмарки umbot измеряют чистое время маршрутизации команд, в то время как другие библиотеки часто включают сетевое взаимодействие с API платформ
    3. Разные приоритетыumbot оптимизирован для сценариев, где важна поддержка нескольких платформ с одним кодом

    Ключевой вывод: в реальных проектах узким местом почти всегда становится либо API платформы (ограничения на RPS), либо ваша бизнес-логика (работа с БД, внешними сервисами) — но не маршрутизация команд.

    Даже при пиковой нагрузке ядро umbot (16 000+ RPS в бенчмарках) обрабатывает запросы быстрее, чем:

    • платформы передают их боту (ограничения API)
    • выполняется типичная логика приложения
    • происходят сетевые запросы к базам данных

    Даже в "реальных" условиях (с фоновой нагрузкой) umbot показывает 16 000+ RPS.

    Что это значит на практике:

    • Средний бот получает ~1-1000 запросов в секунду
    • Даже при пиковой нагрузке (праздники, рекламные акции) у вас будет 15-кратный запас
    • "Узким местом" практически всегда будет API платформы, а не umbot

    Результаты тестирования: На сервере 2 ядра / 4 ГБ RAM (FirstVDS, тариф «Разгон», фоновая нагрузка: 3 сайта + 10 навыков + MariaDB):

    • 16 000 RPS — при 1000 командах и простой логике
    • 4500 параллельных запросов — выполняются без ошибок, и меньше чем за 1с.

    На чистом сервере 1 ядро / 1 ГБ RAM(без фоновой нагрузки, только бенчмарк):

    • 27 000–35 000 RPS — в идеальных условиях

    ⚠️ Важно: RPS сильно зависит от окружения. Цифры выше — ориентиры для сравнения сценариев, а не гарантии. На менее нагруженной системе достигается более высокий RPS

    📊 Контекст: Популярные платформы имеют различные ограничения на частоту запросов — от десятков до нескольких тысяч в секунду в зависимости от тарифа и типа запроса. Показатели umbot находятся на уровне или выше этих ограничений, что означает, что фреймворк не станет узким местом вашего приложения.

    Потребление памяти (инкрементальное, разница до/после инициализации):

    • Базовая инициализация: < 1 МБ
    • 1000 команд: < 1 Б
    • 10 000 регулярок: +8 МБ

    💡 Абсолютное потребление процесса Node.js (~45–60 МБ) не учитывается — это стоимость среды выполнения, а не фреймворка.


    Все тесты открыты и находятся в репозитории:

    # Установка
    git clone https://github.com/max36895/universal_bot.git
    npm install
    npm run build

    # Тест производительности по количеству команд
    npm run bench

    # Стресс-тест на параллельные запросы
    npm run stress

    Полные результаты (включая память, разные типы регулярок, сравнение «первый vs повторный запуск») — в файле BENCHMARKS.md.

    ✅ Подходит, если:

    • Вы разрабатываете единый бот для нескольких платформ.
    • Ожидается высокая нагрузка.
    • Вам важна предсказуемость и простота сопровождения.
    • Вы делаете голосового ассистента, справочник, текстовую игру.

    ⚠️ Рассмотрите альтернативы, если:

    • Вам критично использовать специфические фичи одной платформы (например опросы в Telegram).
    • Вы строите административного бота (баны, модерация, управление чатом).
    • Ваша архитектура требует полной изоляции между платформами.

    По умолчанию umbot использует линейный поиск с поддержкой подстрок и регулярных выражений. Также для команд, обрабатываемых как обычный текст, логика поиска была оптимизирована:

    1. Сначала проверяется точное совпадение
    2. Если точного совпадения нет — выполняется последовательный перебор. Это обеспечивает простоту, предсказуемость и соответствие поведению других платформ (где порядок регистрации важен).

    Однако при числе команд >1000 или в условиях высокой нагрузки вы можете подключить собственный алгоритм поиска:

    const bot = new Bot();
    bot.setCustomCommandResolver((userCommand, commands) => {
    // Пример: возврат команды по хэшу (ваши правила)
    for (const [name, cmd] of commands) {
    if (cmd.slots.some((slot) => userCommand.includes(slot as string))) {
    return name;
    }
    }
    return null;
    });

    💡 Рекомендации:

    Сохраняйте порядок перебора, если он критичен для вашей логики. Используйте кэширование (Map<string, string>) для часто встречающихся фраз. Для fuzzy-поиска рассмотрите fuse.js или natural. При использовании регулярок — не забывайте про защиту от ReDoS.

    Если в вашем приложении используется регулярные выражения для поиска команд, то стоит рассмотреть вариант перехода на re2, за счет чего время обработки может существенно сократиться, а также сократится потребление памяти. При внутреннем тесте при большом числе регулярных выражений (>10 000) использование re2 снизило время обработки в 5–7 раз и уменьшило потребление памяти.

    Долгая обработка команд может быть связана:

    1. Большим количеством команд. В таком случае стоит пересмотреть подход, и переписать сами команды, объединив их при необходимости.
    2. Неоптимальный код в обработчике команды. Сам код команды может быть не оптимальным, и занимать значительную часть времени обработки. Убедитесь что в вашем коде нет тяжелых операций, а если они необходимы, то можно попробовать разбить большую операцию на команды, либо выполнить длительную обработку асинхронно, все запроса пользователя.

    Если в вашем приложении множество изображений или звуков, то рекомендуется их заранее предзагрузить, иначе загрузка ресурса будет происходить во время обработки пользовательского запроса, из-за чего скорость отдачи ответа может сильно упасть. Поэтому стоит заранее подготовить список загружаемых ресурсов, и передать их в Preload.

    umbot — это производительный мультиплатформенный фреймворк, который:

    • Показывает производительность на уровне специализированных решений.
    • Обрабатывает десятки тысяч запросов в секунду на одном VPS
    • Позволяет поддерживать единую кодовую базу для нескольких платформ, сохраняя при этом приемлемую производительность для большинства сценариев использования. Он не решает все задачи — но для диалоговых, интерактивных сценариев он обеспечивает стабильную, предсказуемую и масштабируемую основу.

    Если ваша задача — диалог с пользователем, а не управление чатом, umbot даст вам единый, предсказуемый и масштабируемый фундамент.