Stend_mont/docs/CONTEXT_TEST.md

CONTEXT_TEST

Обновлено: 2026-04-23 (Europe/Moscow)

Цель

Продолжить нагрузочное тестирование маршрута GET /go/{slug} и стабилизировать поведение под конкуренцией.

Что внедрено в API

1. Ограничение ожидания lock-ов:

• добавлен LockTimeoutError;
• allocator_lock(...) теперь поддерживает timeout через pg_try_advisory_lock;
• для user-lock в go_service: GO_USER_LOCK_TIMEOUT_SECONDS (default 2.0);
• для pool-lock: GO_POOL_LOCK_TIMEOUT_SECONDS (default 5.0).

2. Контролируемые ответы вместо долгого зависания:

• timeout user-lock -> 429;
• timeout pool-lock -> 503.

3. Фазовая телеметрия go_service:

• событие: go_service_timing;
• фиксируются времена фаз (wait lock, check existing/limit, ensure/acquire/dispatch/commit, total).

4. Ограничен dispatch runtime-пула:

• POOL_DISPATCH_RETRIES (default 4),
• POOL_DISPATCH_REQUEST_TIMEOUT_SECONDS (default 2.0),
• POOL_DISPATCH_SLEEP_SECONDS (default 0.3).

Что исправлено в тестовом контуре

1. В .env был пустой SIGNING_KEY -> заполнен, api перезапущен.
2. В k6-скрипте включено noCookiesReset: true, иначе возникал ложный вал 401.

Актуальные контрольные результаты

Контрольный тест (после правок):

• профиль: 5 VU, 25s, single-user;
• http_req_failed = 0%;
• open_success = 1138;
• open_rejected = 0;
• p95 http_req_duration = 10.79ms;
• по логам /go/*: 1138 x 303, 1 x 503.

Это подтверждает, что:

• долгие зависания заменены на быстрые контролируемые ответы;
• тестовый сценарий больше не искажается cookie-сбросом.

Следующие шаги

1. Повторить multi-user load (30 VU, 5m) на этом же скрипте и зафиксировать:

• долю 303/429/503,
• p95/p99,
• go_service_timing по фазам.

2. При необходимости тонко настроить:

• GO_USER_LOCK_TIMEOUT_SECONDS,
• GO_POOL_LOCK_TIMEOUT_SECONDS,
• POOL_DISPATCH_*.