Как не убить self-hosted трекер под нагрузкой: серверный минимум, который держит ROI
Под высокий объём трафика трекер ломается не от «слабого VPS», а от узких мест в цепочке: CPU на обработке запросов, диск на записи логов, БД на индексах, сеть на S2S и пиксельных постбэках.
— Выноси БД на отдельный узел, если трекер уже пишет много событий. На одном сервере начинается борьба за I/O: веб, воркеры и SQL душат друг друга.
— Ставь быстрый SSD/NVMe и следи за fsync/flush: трекер живёт на частых мелких записях, а не на «красивом» объёме RAM.
— Кэшируй всё, что не требует мгновенной консистентности: резолв доменов, статические ассеты, очереди для вторичных задач.
— Логи и ретеншн режь жестко: хранить всё «на всякий» = лишняя нагрузка на диск и медленный разбор инцидентов.
Отдельно смотри на сеть: если S2S-постбэки идут через один endpoint без очереди и retry, при всплеске ты получишь потерянные конверсии и грязную атрибуцию. Плюс держи мониторинг latency, 5xx и длины очередей — без этого масштабирование превращается в гадание.
Технический стек определяет потолок вашего ROI. Чистим логи, проверяем постбэки.
Трекер-стек
@tracker_stack_ubt
Как не убить self-hosted трекер под нагрузкой: серверный минимум, который держит ROI
Этот пост опубликован в Telegram-канале Трекер-стек. Подписаться можно по ссылке: @tracker_stack_ubt.