Node.js и производительность

Node.js и AI API: keep-alive, пул соединений и границы timeout

Node.js keep-alive для AI API снижает лишние установки соединения, но не является кнопкой «ускорить всё». Реальная устойчивость зависит от общего deadline, размера пула, очереди, модели, объёма запроса и фактических лимитов проекта. Надёжный server-side клиент RussiaAPI создаёт один управляемый dispatcher, оставляет собственный ключ в runtime и измеряет хвостовую задержку. Тогда команда видит предел системы, а не маскирует его ростом параллельности.

Опубликовано 28 августа 2026 · 11 минут чтения · Ключевой запрос: Node.js keep alive пул соединений AI API

Почему новый fetch на каждый запрос — плохая база

Если приложение создаёт отдельный agent или client в каждом handler, оно чаще открывает новые соединения, усложняет контроль ресурсов и делает shutdown непредсказуемым. Долгоживущий dispatcher с keep-alive повторно использует подходящие соединения и позволяет задать явный верхний предел. Это не означает, что один TCP-сеанс всегда будет доступен: сервер, прокси и сеть могут закрывать соединение, поэтому клиент всё равно обязан корректно обработать ошибку.

Сначала определите обычную и пиковую конкуренцию по конкретному сценарию, а не общий «QPS». Text chat, streaming и асинхронное видео имеют разный профиль времени. Проверьте текущий каталог моделей и доступ проекта, затем начните со скромного пула в staging. Любой числовой limit в статье — пример архитектуры, а не обещание производительности RussiaAPI или модели.

Разделите пул, очередь и upstream limit

Пул соединений ограничивает число сетевых соединений, очередь — число внутренних работ, а лимит gateway может зависеть от проекта или текущей политики. Эти три вещи нельзя подменять друг другом. Слишком большой пул способен усилить всплеск 429, а слишком маленькая очередь делает latency непонятной. Поставьте отдельную границу параллельных модельных вызовов и возвращайте или ставьте в очередь работу по явному правилу продукта.

Наблюдайте время ожидания до вызова и время самого HTTP-вызова раздельно. Если растёт ожидание, возможно, нужна честная очередь или масштабирование worker; если растёт время вызова, увеличивать внутренний concurrency может быть вредно. При 429 не превращайте клиент в генератор повторов: уменьшайте давление, применяйте ограниченный backoff и проверяйте конфигурацию. Практика описана в материале о квоте и очереди.

Устанавливайте deadline сверху вниз

Timeout сокета не равен времени, которое пользователь ждёт ответ. Включите общий AbortSignal на весь сценарий: ожидание в очереди, попытку fetch, ограниченный retry и разбор ответа. Если пользовательский запрос уже отменён, не начинайте новую попытку. Если deadline закончился, завершите работу предсказуемым статусом и зафиксируйте безопасную причину без деталей токена, prompt или внутренней топологии.

Timeout также не говорит, выполнил ли сервер операцию. Для маршрута с побочным эффектом используйте operation ID и собственный журнал состояния. Для чтения или идемпотентного вызова допускается ограниченный повтор при конкретных временных ошибках. Не повторяйте 400/422: это сигнал проверить JSON; не повторяйте 401/403: это сигнал проверить собственный ключ, base URL, model ID и права. Подробности есть в разборе 401/403.

Пример с dispatcher и AbortController

Ниже используется встроенный fetch и dispatcher из undici. Ключ и модель передаются через server-side окружение, а JSON не содержит реального секрета. До production подтвердите версию Node.js и undici в своём runtime: API настройки могут отличаться. Пример показывает один текстовый запрос, а не универсальную совместимость со всеми моделями или streaming-параметрами.

import { Agent, setGlobalDispatcher } from 'undici';

const dispatcher = new Agent({ connections: 12, keepAliveTimeout: 10_000 });
setGlobalDispatcher(dispatcher);

export async function askAi(messages) {
  const signal = AbortSignal.timeout(20_000);
  const response = await fetch('https://russiaapi.com/v1/chat/completions', {
    method: 'POST', signal,
    headers: { 'content-type': 'application/json', authorization: `Bearer ${process.env.RUSSIAAPI_API_KEY}` },
    body: JSON.stringify({ model: process.env.RUSSIAAPI_MODEL, messages })
  });
  if (!response.ok) throw new Error(`ai_api_${response.status}`);
  return response.json();
}

process.on('SIGTERM', async () => { await dispatcher.close(); });

Не передавайте объект headers в клиент или exception целиком в лог. В handler также нужна проверка длины входа и серверная схема результата. Для структурированного ответа применяйте валидацию, не принимая текст модели за команду. Нужный принцип показан в статье о JSON Schema.

Безопасный retry и graceful shutdown

Повтор возможен только для разрешённых временных случаев и в пределах общего deadline. Добавьте jitter, чтобы множество workers не повторяло запрос одновременно. При рестарте приложения перестаньте принимать новую работу, дождитесь короткого периода для уже начатых безопасных операций и корректно закройте dispatcher. Не оставляйте под капотом неограниченные promises: они могут удержать ресурсы и продолжить расход после того, как пользователь уже получил ошибку.

Проверяйте shutdown на тесте: входящий запрос, запрос в очереди, ответ после deadline, 429 и процесс, который получает SIGTERM. Для асинхронной задачи храните состояние вне process memory и защищайте повтор от дубля. Очередь задач видео имеет иные терминальные статусы, поэтому используйте реальную документацию маршрута и тестовый проект, а не переносите пример text API буквально.

Метрики без содержимого запросов

В минимальном наборе полезны: количество стартов, успешных проверок результата, HTTP-класс статуса, p50/p95 общей длительности, время в очереди, число retry, отмены и число открытых/ожидающих работ. Добавляйте model ID только как контролируемое значение с низкой кардинальностью. Не добавляйте user ID, текст ошибки, prompt, ключ, cookie или случайный request payload в label метрики.

Отдельно измеряйте цену успешной задачи, если usage доступен в ответе и ваша политика допускает безопасную агрегацию. Оценка приложения не заменяет консоль или условия договора; методика, период и версия модели должны быть явными. Объединить надёжность и бюджет помогает материал о мониторинге стоимости.

Чек-лист Node.js клиента

1. Dispatcher создаётся один раз на процесс с явными лимитами и корректным закрытием.
2. Очередь, пул и внешняя квота измеряются и ограничиваются отдельно.
3. Общий AbortSignal охватывает ожидание, fetch и retry.
4. Повтор разрешён только для временных случаев без незащищённого побочного эффекта.
5. Ключ, prompt и headers не попадают в браузер, логи или labels метрик.

Схема помогает управлять собственной нагрузкой, но не обещает постоянный latency, квоту или доступность конкретной модели. Сверяйте фактический каталог RussiaAPI и проверяйте изменения на своём тестовом наборе.

FAQ

Читайте также

• OpenAI SDK Node.js
• Timeout и отмена
• Лимиты и очередь
• Документы RussiaAPI