Исследование ёмкости · живой поиск · tazzz.ru
Сколько одновременных поисков реально тянет сервер, сколько люди простоят в очереди и где именно начнёт гореть. Ответ короткий: сегодняшний потолок — искусственный (ручная пятёрка в конфиге), физика позволяет ~150 поисков в час комфортно и ~240 в пределе, а первыми горят не сервер, а крошечные пулы прокси: 4 + 4 + 1 адрес и 4 VPN-устройства на все китайско-корейско-немецкие площадки.
Все цифры — из боевого конфига, замеров и симуляции очереди на реальных длительностях сессий; методика внизу.
Одновременно сейчас
5
Ручной MAX_CONCURRENT_SEARCHES=5 в .env. Fan-out и admission v2 на проде уже включены — потолок держит только эта цифра.
Одновременно физически
11–15
Книга весов памяти (2800 МБ): 11 «дорогих» dongchedi … ~15 на реальном миксе … 35 лёгких РФ-поисков.
Комфортный поток
~150 /час
Ожидание в очереди ≈ ноль, поиск целиком — 0,5–4 минуты. Сегодняшний пик — 8/час.
Жёсткий потолок
~240 /час
Дальше очередь растёт быстрее обработки. Ограничитель — 24 слота воркера деталей, не CPU и не БД.
Залп 30 человек / 5 мин
≤5 мин
Все 30 получают полный поиск максимум за 5 минут; при снятом ручном потолке ожидание в очереди — ноль.
Первым сгорит
прокси
4 адреса dongchedi, 4 encar, 1 mobile.de, 4 VPN-устройства avito, che168 — вообще с IP сервера.
Главная находка ревизии конфига: эпик Э2 (fan-out) на проде фактически уже включён — ADMISSION_CONTROL=v2, DETAIL_DISPATCH_MODE=fanout, GLOBAL_DETAIL_POOL=on, RISK_MODE=on, 24 воркера деталей. Спецификация очереди III писалась от дефолтов кода и считала его невключённым. Значит «включение fan-out» уже позади, и до реальных потолков остаётся один шаг: поднять ручную пятёрку (план Т2.2: 5 → 8 → 12 с наблюдением).
Три последовательных ресурса; у каждого своя пропускная способность. Очередь пользователей стоит перед первым.
| Ступень | Ресурс | Параллелизм | Время |
|---|---|---|---|
| Допуск (admission v2) | книга весов памяти 2800 МБ + живой guard MemAvailable−250 МБ + ручной потолок | 5 (env) / 11–35 (вес) | мгновенно или FIFO-очередь |
| Листинг (скан выдачи площадки) | очередь listing, 3 слота (браузер ~200–400 МБ) | 3 | ~5–15 с |
| Детали (карточка за карточкой) | 24 воркера detail_fetch, общий пул, анти-бан-капы площадок | 24 глобально | 6–25 с/машина |
Медианы деталей из Loki за 48 ч: dongchedi 7,4 с · che168 6,1 с · encar 17,5 с. Медианные сессии (история 60 дней): dongchedi 29 с / 42 машины · che168 51 с / 29 · encar 12 с / 49. Хвосты честно длинные: p95 сессии dongchedi — 37 минут (большие выдачи).
| Площадка | Вес, МБ | Анти-бан-кап деталей | Чем обеспечен | Потолок площадки, сессий/час |
|---|---|---|---|---|
| DongCheDi | 250 | 12 | 4 прокси × 3 фетча | ~140 |
| Che168 | 120 | 4 | IP сервера (DIRECT, прокси нет) | ~80 |
| Encar | 120 | 16 (risk: до памяти) | 4 прокси — 4–6 параллельных на адрес | ~65 |
| Avito | 80 | = пулу VPN | 4 residential-устройства (живой опрос) | ~19 |
| mobile.de | 250 | 4 | 1 прокси | ~23 |
| Drom / Auto.ru | 80 | — (до 24) | прямой HTTP, дёшево | сотни |
«Потолок площадки» = кап ÷ время детали × 3600 ÷ машин на сессию — сколько сессий площадка переварит за час, если жать её одну. Сумма капов (43+) больше 24 воркеров — при смешанной нагрузке первым упирается общий пул.
Дискретная симуляция: пуассоновский приход, реальный микс площадок (история), admission по книге весов, 3 листинг-слота, 24 слота деталей с капами, round-robin общего пула. Ожидание = от нажатия «Найти» до старта поиска.
| Поисков/час | Ожидание p50 | Ожидание p95 | Вердикт |
|---|---|---|---|
| до 90 | 0 с | 1 с | никто не ждёт |
| 120 | 1 с | 29 с | почти никто |
| 150 | 1 с | 63 с | хвост начинает ждать |
| 180 | 18 с | 2,9 мин | очередь ощутима |
| 210+ | 3 мин | 14 мин | коллапс: хвост копится |
| Поисков/час | Ожидание p50 | Ожидание p95 | Поиск целиком p95 | Вердикт |
|---|---|---|---|---|
| до 180 | 0 с | 1 с | 3,9 мин | никто не ждёт |
| 210 | 1 с | 53 с | 5,9 мин | терпимо |
| 240 | 63 с | 5,4 мин | 10,7 мин | колено: 24 слота деталей |
| 270+ | 9,5 мин | 24 мин | 28 мин | коллапс |
Спецсценарии: залп 30 человек за 5 минут — при потолке 5 ожидание p50 55 с, максимум 4 минуты, все дожидаются; со снятым потолком ожидания нет вовсе (максимум готовности — 5,2 мин). Волна из 20 поисков DongCheDi за 10 минут — книга весов пускает 11 одновременно, худший ждёт 109 с, все 20 готовы за ~5 минут.
Честные оговорки модели: она считает от медиан — реальные p95-хвосты (сессия dongchedi до 37 минут) при потолке 5 могут удерживать слот на десятки минут, так что нынешний конфиг хрупче модели именно на хвостах; продвижение очереди помимо хуков подстраховано свипом раз в 2 минуты (до +2 мин к ожиданию в редких гонках); переполнение очереди отдаёт отказ при 30 ждущих (и максимум 6 на пользователя — защита от абьюза).
Настоящий внешний ограничитель — антибот площадок. Защита-предохранитель: 8 ошибок за 120 секунд по площадке → пауза диспатча этой площадки на 30 минут ДЛЯ ВСЕХ пользователей.
Прокси для che168 — ноль: DIRECT-режим. Живой замер 2026-06-26: 24 одновременных запроса с одного IP → API мгновенно отдаёт мусор и сажает адрес в пенальти (после буреста даже 4 потока валятся). Кап 4 — не перестраховка, а измеренная граница. Если IP сервера попадает в пенальти — che168 гаснет для всех разом, и это тот же IP, с которого ходит всё остальное DIRECT.
DongCheDi: 4 прокси (кап 12 = 4×3); потеря одного адреса = −25% ёмкости площадки. Encar: 4 прокси, а risk-режим разрешает до ~22 параллельных деталей — по 5–6 на адрес; предохранитель это переживёт, но баны адресов при устойчивой волне — вопрос времени. Mobile.de: один прокси. Avito: 4 residential-устройства (DataDome; жадность ловится мгновенно), потолок ~19 сессий/час. Хорошая новость: прокси — самый дешёвый и самый линейный апгрейд ёмкости из всех возможных.
Волна поисков одной площадки → рост ошибок → 8 за 2 минуты → площадка на паузе полчаса у всех (авто-восстановление по TTL). Для пользователя это выглядит как «поиск нашёл меньше обычного» или зависшие карточки. Это осознанная защита (лучше пауза, чем бан адресов), но при снятии ручного потолка частота таких пауз — главное, за чем смотреть в канарейке Т2.2.
Что ещё может сломаться, при каких условиях, как проявится и что его сдерживает.
| Сценарий | Порог/условие | Симптом | Сдерживает |
|---|---|---|---|
| Диск: фото-кэш | свежая сессия ≈ 48 МБ фото; свободно 34 ГБ, GC хранит 7–30 дней | при сотнях «свежих» сессий/день диск кончается за дни; устойчиво без апгрейда ≈ 100–200 свежих сессий/день (повторы машин фото не перекачивают) | GC ежедневно; решение — S3-миграция фото (план уже есть) или диск ≥120 ГБ (Э4) |
| Память / OOM | кампания + пики поиска + сосед horeca (~450 МБ неучтённых) | guard MemAvailable−250 придерживает новые поиски → очередь растёт при формально свободных слотах; глубже — swap-трэш на HDD | guard + max-memory-per-child 150 МБ + jemalloc; после выноса horeca (Э5) бюджет честный |
| HDD под двойной нагрузкой | поиски (запись фото+БД) поверх кампании | случайные чтения PG дорожают, всё вязнет по 3 мс/чтение | страничный кэш; лечится только SSD (Э4) |
| Оркестрация: 2 слота control | очередь default,parsing и переводы на одном воркере ×2 | задержка старта листингов при шторме коротких задач | задачи короткие; дренаж проекций ограничен бюджетом 45 с |
| Переводы/LLM-бюджет | волна НОВЫХ китайских машин → батчи конфигов в OpenRouter | рост очереди переводов (конфиги доезжают позже), расход кредитов пропорционален новым машинам | глобальный RPM-лимитер + словарный кэш + Google-фолбэк; write-back «перевёл раз — сохрани» |
| VPN-оркестратор недоступен | внешний сервис пула устройств | Avito гаснет (только он); кэш последнего размера пула смягчает моргания | изоляция по площадке; предохранитель |
| Redis падает | единственный инстанс, 29 МБ, без maxmemory | живые сессии теряются; при рестарте воркеров зависшие помечаются отменёнными; поиск недоступен до подъёма | restart unless-stopped; сессии по TTL; чистка на старте |
| Postgres соединения | max_connections 400; сейчас ~30; худший теоретический ~150 | — | запас ×2,5 даже в худшем случае |
| Абьюз очереди | лимиты: очередь 30, максимум 6 на пользователя | 5–6 злоумышленников с ботами забивают очередь → отказы новым | лимиты есть; при росте аудитории снизить per-user до 2–3 |
| DDoS на поиск | эндпоинт требует JWT; nginx 10 r/s на IP | гостевым флудом не пробивается; ботнет с аккаунтами упрётся в очередь-30 | nginx + JWT + лимиты очереди |
| Один сервер на всё | любой отказ железа/хостера | всё разом: сайт, поиск, БД, фото | только бэкапы; горизонт — второй сервер (вопрос B и дальше) |
| «Все площадки банят разом» | болезнь прокси-провайдера / гео-блок РФ-адресов | живой поиск деградирует до «Из БД» (склад работает, свежие — нет) | предохранители по площадкам; склад из 480 К машин остаётся |
В порядке «дешевле и раньше — вперёд». Каждая ступень умножает конкретный ограничитель.