Шакальный ярус: замеры

Проверка идеи: хранить все фото всех машин в предельно ужатом качестве (мгновенный показ полной галереи), обложки — в нормальном, а при открытии карточки догружать нормальное качество за секунды. Ниже — живое сравнение качества на реальном кадре, вес каждого уровня на весь корпус и замеренная скорость догрузки.

Вердикт: идея рабочая, и в текущий диск влезает — с двумя уточнениями.

Разумный «шакал» — 320px / q45 ≈ 7 КБ на фото: на все 5,43 млн иностранных фото — 33 ГБ, а на гео-критичные площадки (dongchedi + che168 + encar, у которых CDN не отвечает РФ-браузеру) — 15,7 ГБ. Вместе с обложками сетки и рабочим множеством — ≈21 ГБ: влезает в свободные 32 ГБ уже сегодня, 0 ₽/мес. mobile_de (Германия) из РФ грузится — его шакал можно отложить до докупки диска.
Догрузка нормального качества замерена: encar 0,7 с, che168 1,7 с, mobile_de 4,0 с, dongchedi — обычно 3–5 с с хвостом (см. §03). Подменять кадры надо по одному по мере готовности, тогда хвост ничего не блокирует: пользователь просто видит, как галерея «проявляется».

Как выглядит шакал — смотрите сами

Реальный кадр dongchedi (оригинал 2048px), показанный на ширину модалки. Переключайте уровни — подпись показывает вес кадра и цену уровня на весь корпус:

Кадр объявления dongchedi в выбранном качестве

этот кадр: в среднем по площадкам: все 4 площадки: гео-критичные: растяжение:

Экземпляр кадра легче среднего по dongchedi (сцена простая) — веса «в среднем» в подписи считаются по выборке n=6 на площадку. На узком экране растяжение меньше и шакал выглядит лучше, чем на десктопе.

Лестница качества и цена уровня

Уровень	dongchedi	mobile_de	encar	che168	Все 4 (5,43 млн фото)	Гео-критичные (2,61 млн)
480 / q72 = нынешний thumb	19,7 КБ	16,6 КБ	9,1 КБ	20,6 КБ	87,7 ГБ	44,0 ГБ
400 / q55	11,6 КБ	10,5 КБ	5,9 КБ	12,4 КБ	53,7 ГБ	26,2 ГБ
320 / q45	6,9 КБ	6,7 КБ	3,9 КБ	7,5 КБ	33,3 ГБ	15,7 ГБ
256 / q38	4,2 КБ	4,2 КБ	2,5 КБ	4,7 КБ	20,9 ГБ	9,7 ГБ
200 / q32	2,6 КБ	2,6 КБ	1,7 КБ	2,9 КБ	13,0 ГБ	6,1 ГБ
160 / q28	1,7 КБ	1,8 КБ	1,2 КБ	1,9 КБ	8,7 ГБ	4,1 ГБ

Средний вес одного фото WebP при данной длинной стороне и quality (замер живьём, n=6/площадку). Дедуп по content-hash (уже в хранилище) итог только уменьшит — повторные кадры перепарсов и перепубликаций хранятся один раз.

Что влезает в диск сегодня

Свободно 32 ГБ; минимум 10 ГБ оставляем нетронутыми (переполнение диска = отказ записи Postgres), рабочий бюджет — ≈22 ГБ. Сумма = шакал + обложки сетки (×1 в 480/q72 = 5,2 ГБ или ×3 = 15,5 ГБ) + рабочее множество догретых галерей (0,3 ГБ):

Комбинация	Итого	В бюджет 22 ГБ	Комментарий
Гео-шакал 320/q45 + обложки ×1	21,2 ГБ	влезает	рекомендуемый старт: 0 ₽/мес
Гео-шакал 256/q38 + обложки ×1	15,2 ГБ	влезает	запас больше, мыло заметнее
Гео-шакал 200/q32 + обложки ×3	21,9 ГБ	впритык	если обложек хочется три
Все площадки 320/q45 + обложки ×1	38,8 ГБ	нет	нужно ~+30 ГБ диска
Все площадки 320/q45 + обложки ×3	49,1 ГБ	нет	полный вариант: ~+40–50 ГБ диска
Все площадки 480/q72 (шакал = thumb)	≈93–104 ГБ	нет	это уже «все превью», обложки не нужны

Докупка NVMe у Timeweb по конфигуратору ≈ 16,5 ₽/ГБ/мес → +50 ГБ ≈ 830 ₽/мес, +100 ГБ ≈ 1 650 ₽/мес (проверить в панели — отдельный сетевой диск может быть дешевле). Поэтому старт «в текущий диск» — самый выгодный.

Догрузка нормального качества: замер

Полный цикл на открытии карточки: скачать все кадры с CDN источника (параллельно, с настроенными потолками) + перекодировать в full-1600 и превью. Одна живая галерея на площадку, 31.08.2026:

Площадка	Кадров	Успех	Параллельность	Стена (fetch + encode)	Скачано
encar	20	20/20	50	0,68 с	0,4 МБ
che168	20	20/20	30	1,68 с	0,9 МБ
mobile_de	20	20/20	50	4,02 с	1,4 МБ
dongchedi	17	17/17	30	14,07 с *	3,8 МБ

* Из 14 с — 10 с съел таймаут одного кадра с последующим добором через прокси; без него галерея собирается за ~4 с. Это и есть довод за покадровую подмену: шакал уже на экране, каждый готовый кадр заменяется на чёткий независимо, хвостовой кадр никого не держит. Ожидание «2–4 с до нормального качества» подтверждается для большинства кадров всех площадок; полная галерея dongchedi в худшем случае доезжает за ~15 с.

UX-схема подтверждена замером. Открытие модалки: мгновенно вся галерея в шакале (с нашего диска, ~7 КБ/кадр — быстрее любого хотлинка) → фоновый прогрев в порядке показа → чёткие кадры проявляются в течение 1–4 с, начиная с первого. Слепых квадратов нет ни в один момент.

Цена наполнения (бэкфилл)

Чтобы построить шакал, оригинал каждого фото надо скачать один раз (заодно в тот же проход бесплатно строятся обложки — трафик общий). Важно: 885 ГБ ниже — транзит, а не хранение. Оригинал живёт только в оперативке между скачиванием и перекодированием и на диск не пишется вовсе: сохраняются только обложка (480px, ~20 КБ) и шакалы (~7 КБ) — итого ~140 КБ на машину вместо ~6 МБ оригиналов. Скорости прямого канала с прод-IP дают:

dongchedi — 2,07 млн фото при 13 фото/с ≈ 44 ч чистыми (узкое место всего бэкфилла);
mobile_de — 2,82 млн при 72/с ≈ 11 ч; encar — 2,8 ч; che168 — 2,1 ч (идут параллельно dongchedi);
суммарно скачивается ≈ 885 ГБ входящего трафика (у Timeweb бесплатен), с дросселированием — 3–4 суток фоном;
CPU на перекодирование мелкого шакала — фон на 4 ядрах, вписывается (замер: ~10+ кадров/с на full-варианты, шакал легче);
порядок: dongchedi → che168 → encar (гео-критичные), mobile_de — последним или после докупки диска.

Против схемы «только обложки» из основного отчёта эта добавляет ~16 ГБ хранения и ~2 суток бэкфилла, а взамен даёт мгновенную полную галерею всегда — и заодно страховку для «Из БД»: у мёртвых объявлений (источник удалил фото) галерея сохраняется хотя бы в шакале, а не только 1–3 обложки.

Доступность фото и вымирание ссылок (замер 31.08)

По каждой площадке скачаны пачки фото свежих и старых объявлений с прод-IP (боевые заголовки, параллельность 12; для упавших дополнительно проверен боевой каскад с прокси-пулом):

Площадка	Свежие (авг.)	Старые (июнь)	Медиана	Причина смертей
dongchedi	24/24 · 100%	3/24 · 12%	0,52 с	403 на подписанных ссылках — мертвы с любого IP, прокси не спасает (0/6)
mobile_de	24/24 · 100%	8/24 · 33%	0,28 с	404/410 — объявления проданы/сняты, не восстановимо (0/6)
che168	24/24 · 100%	24/24 · 100%	0,86 с	вымирания не видно
encar	24/24 · 100%	24/24 · 100%	0,16 с	вымирания не видно
drom / autoru / avito	70/70 · 100%	72/72 · 100%	0,04–0,07 с	кэш им и не нужен — браузер РФ грузит сам

Кривая вымирания по возрасту объявления

Возраст	dongchedi живо	mobile_de живо
1–2 недели	100%	100%
3–5 недель	41%	— (нет машин в окне)
6–8 недель	33%	82%
2–2,7 месяца	8%	50%

Следствие: бэкфилл — это спасательная операция, и она срочная. 82% машин dongchedi и 99,8% mobile_de спарсены в июне — в зоне, где живо 8–12% и ~40–50% фото соответственно. Оценка спасаемого сейчас: dongchedi ~15% фото (~320 тыс.), mobile_de ~40–50% (~1,2–1,4 млн), che168 и encar — почти всё. Итого ~2,1–2,2 млн из 5,43 млн (~40%), и каждая неделя промедления съедает ещё часть июльской когорты dongchedi. Порядок бэкфилла: dongchedi (сначала август и июль) → mobile_de → encar/che168 (последние два стабильны, им спешка не нужна). Хранение спасённого — соответственно меньше расчётного: гео-шакал ужимается с 15,7 до ~5 ГБ, mobile_de — с 18,9 до ~9 ГБ. Флаг шакала-на-парсинге надо включать не дожидаясь бэкфилла — каждое новое объявление с этого момента перестаёт терять фото.

Что это меняет в плане включения

В image_store.VARIANTS добавляется третий вариант shakal (320px/q45, суффикс .s.webp) — раскладка, дедуп и url-ключи те же.
cache_car_images на парсинге/бэкфилле строит шакал всех кадров + обложку ×1 (вместо covers-only из основного плана); полный прогрев — по открытию карточки, как и планировалось.
Фронт: <img> сетки — обложка; модалка — шакал сразу, подмена на full по мере готовности (по одному кадру, событие/поллинг уже есть в механике карточек).
GC не трогает шакал и обложки (вечные ярусы), вытесняет только full-галереи по lastview — как в основном плане.
Остальное из основного отчёта без изменений: локальный диск, url-ключи для всех площадок, гейт по обложкам, мониторинг df.