Производительность

Производительность

Раздел описывает настройку параллелизма и пропускной способности RouterAI в режиме Standalone — когда всё приложение, включая PostgreSQL, работает в одном контейнере.

Если одного контейнера недостаточно — см. Масштабирование.

Как работает параллелизм

RouterAI использует Puma в качестве веб-сервера. Каждый API-запрос к модели блокирует поток Puma на всё время ожидания ответа (синхронный HTTP-прокси). Поэтому количество одновременных запросов к моделям равно суммарному числу потоков Puma.

Формула:

Одновременных запросов = WEB_CONCURRENCY × RAILS_MAX_THREADS

Настройки по умолчанию

Контейнер запускается с максимальными настройками для Standalone-режима:

Переменная По умолчанию Описание
WEB_CONCURRENCY 8 Количество Puma worker-процессов
RAILS_MAX_THREADS 10 Количество потоков на каждый worker
DATABASE_POOL 11 Размер пула DB-соединений на процесс
JOB_CONCURRENCY 2 Количество процессов Solid Queue

Итог: 8 × 10 = 80 одновременных запросов, 8 × 11 + 2 × 3 = 94 DB-соединения (вписывается в max_connections=100 встроенного PostgreSQL).

⚠️ Увеличение RAILS_MAX_THREADS выше 16 не даёт прироста производительности из-за GVL (Global VM Lock) Ruby.

Рекомендуемые значения для разных нагрузок

Уменьшайте настройки только если сервер испытывает нехватку RAM или нужно снизить нагрузку на PostgreSQL:

Нагрузка WEB_CONCURRENCY RAILSMAXTHREADS DATABASE_POOL Одновременных запросов
Лёгкая (dev/test) 2 5 6 10
Средняя 4 8 9 32
Высокая (production) 8 10 11 80

Для изменения настроек передайте переменные окружения при запуске контейнера (через compose.override.yml или флаг -e в docker run).

⚠️ Если 80 одновременных запросов недостаточно или нужна высокая доступность — переходите на режим масштабирования с внешним PostgreSQL.

Связанные разделы