Ёмкость без закупок

Отчёт считал «4 dongchedi + 4 encar + 1 mobile.de». Таблица proxies показывает: dongchedi и encar записаны на одни и те же четыре адреса 79.172.218.{214, 230, 247, 165}. Для банов это не страшно (баны — по паре «IP × целевой сайт»), но потеря одного адреса — это −25% ёмкости обеих площадок сразу, а не одной.

Проба всех адресов против api.encar.com: три отвечают за 0,7–1,2 с, .165 висит до таймаута 12–20 с на любой цели. При PROXY_SELECTION=random это значит: каждый четвёртый фетч dongchedi и encar сгорает в таймаут, раздувает медианы и кормит окно предохранителя ложными сбоями — тот самый механизм, что ставит площадку на паузу 30 минут для всех.

Почему слепа: счётчики success_count/failure_count в таблице proxies — нули, last_used_at пуст; статистика ProxyRotator живёт в памяти каждого из 24 процессов отдельно и умирает вместе с ними; метка proxy:dead ставится только в части путей и живёт 120 с. Ни health-проб, ни общего реестра нет.

Поэтапный тайминг из Loki за 7 дней (n=289) показывает: у encar фетч с площадки — 5,6 с из 13,9 с задачи, у dongchedi — 2,5 с из 18,6 с. Остальное — наша собственная работа: запись в Postgres на HDD с синхронным коммитом (1,7–4,8 с), инлайновый LLM-подбор мощности в расчёте цены (p90 — 31 секунда внутри слота), последовательные под-запросы. Жёсткий потолок «240 поисков/час» — это 24 слота × раздутое время; лечится диетой слота, а не железом. Разбор — в §02.

Вес dongchedi в admission — 250 МБ с комментарием «Playwright». Фактически листинг и детали dongchedi с июня идут через JSON-API (curl_cffi); за 7 дней Loki слово «playwright» встречается в логах воркеров 6 раз. Честный вес — ~120 МБ, как у che168/encar. Одна строка конфига удваивает допуск dongchedi-тяжёлых миксов: 11 → ~23 одновременных.

Классический живой поиск ставит no_cache=True: каждая машина листинга уходит в полный детальный фетч, даже если она в базе с полной карточкой. По 60 дням прода уже в базе были: encar — 45%, mobile.de — 54%, dongchedi — 40%, che168 — 28% машин живых сессий. При этом листинг уже несёт живую цену и пробег — то есть свежесть проверяема без детального фетча. С ростом трафика доля повторов только растёт: это главный расход прокси-бюджета впустую.

Режим «Свежие» доказывает актуальность машины полным перепарсом детали — хотя сам факт присутствия в листинге с живой ценой и пробегом уже доказывает всё, что меняется у машины со временем. ТТХ, комплектация, отчёт осмотра — неизменяемы. Платим за это дефицитнейшим ресурсом: запросами с четырёх прокси-адресов.

Фетч (внешний, дефицитный) и обработка (внутренняя, дешёвая при правильном исполнении) занимают один слот последовательно. Пока слот пишет 4,8 с в Postgres на HDD или 31 с ждёт LLM, он не фетчит — а именно числом одновременных фетчей меряется анти-бан-кап площадки. Слот-время = потолок, и две трети слот-времени не относятся к площадке.

Выбор случайный, здоровье не проверяется, статистика не переживает процесс, предохранитель считает сбои по площадке целиком — поэтому один мёртвый адрес и таймауты от него неотличимы от бана площадки и способны погасить её для всех пользователей на 30 минут. Фиксированные капы (12/4/16) — догадки, а не измеренные пределы: реальный безопасный темп каждого IP никто не ищет.

Что делаем. В on_page_parsed вместо безусловного no_cache — трёхходовая развилка: машина есть в БД с полной карточкой и цена/пробег листинга совпадают с сохранёнными → отдать карточку из БД как свежую (листинг только что подтвердил, что она живая и цена та же; data_freshness = сейчас). Цена изменилась → пересчитать «под ключ» от листинговой цены локально (расчёт — наш код, 0 внешних запросов) и поставить фоновый refresh детали вне слота. Новая машина → полный фетч, как сегодня.

Что даст. Минус 40–50% детальных фетчей уже при сегодняшнем трафике (замер §02) → прокси-бюджет и слот-время сессии падают почти вдвое, потолки площадок в сессиях/час растут в ~1,5–1,7 раза, «время до полной выдачи» на повторных машинах — секунды вместо минут. Выигрыш растёт с трафиком. Сюда же — коалесценция точных дублей (15% сессий): одинаковый (площадка × фильтры) в пределах пары минут присоединяется к уже идущей сессии.

Риск и проверка. Риск продуктовый: карточка могла стать полнее с момента сохранения (гейт pipeline_complete уже это ловит). Канарейка: метрика «доля деталей, отданных дельтой» + жалобы на устаревшие данные; кнопка «Обновить» на карточке остаётся как ручной форс.

Что делаем. Три независимых правки.

• Запись в БД. SET LOCAL synchronous_commit=off на транзакции upsert'а parsed_cars (данные переспарсиваемы; по документации PG это не риск целостности — лишь окно ~0,6 с при падении сервера) + wal_compression=on + вынести raw_json из горячего пути. Ожидание: 1,8–4,8 с → 0,2–0,5 с.
• LLM вне слота. Промах кэша мощности не блокирует слот 30 секунд: карточка эмитится без «под ключ», отдельная задача в control-очереди добирает л.с. и дорассчитывает цену, фронт получает обновление существующим путём update_car_to_full. Убивает p90=31 с этапа «расчёт» dongchedi.
• Диета запросов encar. Карточка и отчёт осмотра — параллельно, а не последовательно; HTML-страницу fem.encar.com не тянуть, когда inspection-ID извлекается из URL фото (этот путь уже есть — сделать его основным); одна keep-alive HTTP/2-сессия. Фетч 5,6 с → ~3–3,5 с и вдвое меньше запросов на машину — то есть вдвое больше сессий на тот же анти-бан-кап.

Что даст. Среднее слот-время: dongchedi 18,6→~5 с, encar 13,9→~5,5 с, che168 5,3→~3,5 с. По формуле потолка (24 слота × 3600 ÷ слот-время ÷ машин на сессию): жёсткий потолок ~240/ч → ~600/ч на тех же 24 слотах. Вместе с Р1 внутренний потолок уходит за 1000/ч — ограничителем становятся площадки, как и должно быть.

Риск и проверка. synchronous_commit — канон PG (см. методику); канарейка по метрике save_ms в Loki (она уже пишется). LLM-вне-слота меняет порядок появления цены на карточке — фронт уже умеет жить с поздним total_cost (механизм существует).

Что делаем. (1) Реестр здоровья в Redis + beat-проба раз в минуту лёгким запросом; мёртвый адрес исключается для всех процессов сразу, счётчики пишутся в таблицу proxies (она уже есть — просто не используется). (2) Предохранитель считает сбои по паре «площадка × egress-IP»; вся площадка встаёт на паузу, только если легли все её маршруты. (3) Вместо фиксированных капов — токен-бакет на IP с адаптивным темпом AIMD: успех длится — темп медленно растёт, 429/капча — темп мгновенно вдвое вниз. Система сама находит реальный безопасный предел каждого адреса, вместо того чтобы вечно жить на догадке. (4) che168 и mobile.de получают общий пул как дополнительные маршруты (проба §02 подтвердила доступность).

Что даст. Сегодняшние 25% фетчей-в-таймаут исчезают (минус ложные сбои → минус ложные 30-минутные паузы). che168: 1 маршрут → 5, потолок площадки ~80 → ~300+ сессий/час, SPOF снят. Реальные потолки площадок перестают быть константами в коде и начинают измеряться автоматически.

Риск и проверка. AIMD стартует с сегодняшних консервативных капов и растёт только на длительном успехе — хуже сегодняшнего не станет по построению. Метрика канарейки: частота срабатываний предохранителя по маршрутам (уже есть колокольчик админки).

Что делаем. Воркер деталей переводится с 24 prefork-процессов на --pool=threads с 32–64 потоками. Детальная задача — чистое ожидание (сеть площадки, БД, LLM): эксперимент §02 подтвердил, что curl_cffi отпускает GIL, слой БД — на потокобезопасном scoped_session, а переводчик уже носит внутренние локи (он живёт в многопоточном gunicorn). Канарейка: второй контейнер деталей на потоках забирает часть очереди, неделя наблюдения, потом полный переход.

Что даст. Книга весов admission растёт с 2800 МБ до ~5500 МБ: одновременных поисков 11–15 → 25–35 (вместе с честным весом dongchedi из К4). Слоты деталей перестают быть дефицитом: 24 → 48–64 без роста памяти — жёсткий потолок из «24 слота» превращается в «сколько разрешают площадки». Исчезает и постоянная замена раздутых процессов (max-memory-per-child).

Риск и проверка. Главный риск — неявно непотокобезопасные углы в 5000-строчном переводчике и скраперах; поэтому канарейка, а не выкатка. Утечки памяти в одном процессе копятся — лечится плановым рестартом контейнера раз в сутки (ночное окно уже есть у кампаний).

• Вес dongchedi в книге весов 250 → 120 МБ (К4): допуск dongchedi-миксов ×2 одной строкой.
• MAX_CONCURRENT_SEARCHES 5 → 8 → 12 по плану Т2.2 — теперь с уверенностью, что fan-out в проде уже живёт.
• Прокси-строки che168 в таблицу proxies (существующие 4 адреса) — SPOF серверного IP снят до всякого реестра.
• Убрать мёртвый .165 из ротации руками — четверть фетчей dongchedi/encar мгновенно перестаёт гореть в таймаутах (до появления реестра Р3).
• wal_compression=on в Postgres — дешевле WAL на HDD.