universal_bot-ts

Производительность и гарантии времени выполнения

Введение

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

Гарантия времени выполнения библиотеки

umbot гарантирует, что её собственная обработка одного входящего запроса (от получения до формирования готового к отправке объекта ответа) не превысит 1 секунду в подавляющем большинстве реальных сценариев использования.

Важно: Это время не включает:

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

Таким образом, разработчику, использующему umbot, остается около 2 секунд из общего 3-секундного лимита платформы для реализации своей прикладной логики.

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

Компоненты времени выполнения библиотеки

Время, которое umbot тратит на свою внутреннюю обработку, включает:

1. Инициализация запроса: Разбор входящего JSON, извлечение команды пользователя, идентификатора сессии и других параметров.
2. Поиск команды: Проход по зарегистрированным командам и проверка соответствия.
   • Для команд с isPattern: true – компиляция (если не в кэше) и выполнение регулярных выражений.
3. Работа с пользовательскими данными: Чтение и сохранение состояния пользователя в выбранном хранилище (файловая система или БД).
4. Формирование ответа: Подготовка объекта ответа, включая:
   • Загрузка и кэширование медиафайлов: При использовании Card.addImage(...) или Sound.addSound(...) с путями к файлам, библиотека автоматически загружает файл на сервер платформы, получает его token и сохраняет в БД для последующего использования.
5. Сохранение логов: Запись информации о запросе и ответе.
6. Подготовка финального объекта ответа для отправки обратно платформе.

Сценарии производительности и замеры

Ниже приведены результаты тестирования времени выполнения только внутренней логики библиотеки (шаги 1-6 выше), исключая время выполнения action. Тесты проводились на системе с AMD Ryzen 5 5600G, 32 ГБ ОЗУ, SSD.

Примечание: Время первичной загрузки новых изображений или аудиофайлов (когда token для файла ещё не кэширован в БД) может значительно превышать 1 секунду и выделено отдельно. После первой загрузки и кэширования, последующие обращения к тем же файлам выполняются быстро.

Кэширование регулярных выражений

Особое внимание уделено оптимизации работы с регулярными выражениями (RegExp). При использовании isPattern: true, umbot кеширует скомпилированные RegExp объекты (с политикой LRU при достижении лимита MAX_CACHE_SIZE = 300). Это означает, что при первом вызове run() с командами, использующими новые паттерны, происходит * *компиляция RegExp, что занимает больше времени. При последующих вызовах с теми же паттернами, * *скомпилированные RegExp берутся из кэша, что значительно ускоряет выполнение.

Таблица результатов

Сценарий	Кол-во команд	Кол-во актив. фраз	Из них рег. выражений	Первичная загрузка изображений	Наилучший результат	Средний результат	Наихудший результат	Комментарии
Простой поиск (только слова)	2	2	0	Нет	0.5 мс	1.2 мс	3.0 мс	Типичный простой навык.
Сложный поиск (много команд, без регулярок)	2000	2000	0	Нет	5.43 мс	5.63 мс	6.47 мс	Сложный навык, без паттернов.
Поиск с регулярными выражениями (кэш не прогрет)	2000	2000	2000	Нет	5.495 мс	6.47 мс	6.62 мс	Паттерны кэшированы (RegExp в Text.regexCache). Эти цифры соответствуют реальному сценарию с 2000 регулярками.
Поиск с регулярными выражениями (кэш прогрет)	2000	2000	2000	Нет	1.72 мс	2.04 мс	2.54 мс	Проверка всех команд с прогретым кэшем.
Загрузка изображений (кэш пуст)	10	20	0	2 изображения (по 1 МБ)	200 мс	600 мс	1100 мс*	*Время может превысить 1 секунду.
Загрузка изображений (кэш полон)	10	20	0	2 изображения (уже закэшированы)	1.0 мс	2.5 мс	5.0 мс	Быстро, т.к. token уже есть.
Экстремальный сценарий (тестирование, много регулярных выражений)	2,000,000	0	2,000,000	Нет	6.05 мс	148.8 мс	339.0 мс	Только регулярные выражения, кэш RegExp (LRU, размер 300).

*Наихудший результат в строке “Загрузка изображений (кэш пуст)” превышает 1 секунду, что соответствует описанию выше. Это единственный сценарий в таблице, который может превысить гарантию. Для решения этой проблемы, желательно предварительно загрузить все необходимые ресурсы. Сделать это можно заиспользовав класс Preload.

Сценарии, при которых может быть превышено 1 секунда

• Первичная загрузка новых медиафайлов: Как показано в таблице, загрузка новых изображений или аудиофайлов может занять значительное время (сотни миллисекунд или более), особенно если файлы большие или сервера платформы перегружены. Это основной фактор, который может превысить 1 секунду библиотеки.
• Очень большое количество команд с очень сложными регулярными выражениями (ReDoS), одновременно используемых в одном запросе, и все они “холодные” (кэш пуст). Это маловероятно при разумном использовании и при условии, что проверка ReDoS реализована на этапе добавления команды. Обычно кэш RegExp быстро “прогревается”.
• Критические системные сбои (например, проблемы с GC, перегрузка CPU/диска на сервере).

Заключение

umbot демонстрирует отличную производительность для основной логики обработки запросов. Благодаря эффективному кэшированию (RegExp, userData, токены медиа), повторные вызовы run() выполняются значительно быстрее, чем первые. В реальных сценариях (без первичной загрузки файлов) внутреннее время библиотеки намного меньше 1 секунды, оставляя разработчику значительное время для его логики. Узким местом является первичная загрузка медиафайлов, но это разумный компромисс для удобства автоматического кэширования. Библиотека надежно укладывается в 1 секунду для всех остальных операций.

This site is open source. Improve this page.