Self-hosted трекер под нагрузкой: где сервер начинает душить ROI

Self-hosted трекер под нагрузкой: где сервер начинает душить ROI

У self-hosted трекера узкие места почти всегда одни и те же: CPU на парсинге постбэков, I/O на записи логов и сеть на пиковых всплесках кликов. Если трекинг тормозит, вы теряете не только скорость, но и атрибуцию: часть конверсий уезжает мимо окна, часть событий приходит вразнобой.

Схема для живой системы простая:
— выносите БД на отдельный диск/том, без соседства с тяжелыми логами;
— разносите веб-сервер, воркеры и очередь по разным процессам;
— включайте буферизацию записи и ротацию логов, иначе диск станет бутылочным горлышком;
— на пиках режьте лишние запросы к аналитике, оставляйте только критичный путь: click -> token -> postback.

Под нагрузкой важнее не «мощный сервер», а предсказуемый стек. Проверяйте latency между web, DB и queue, следите за количеством медленных запросов, размером очереди и временем ответа на постбэк. Если один компонент начинает копить хвост, масштабировать весь хост бессмысленно — надо чинить именно этот слой.

Чистим логи, проверяем постбэки. И помните: технический стек определяет потолок вашего ROI. Правильный набор CPU, RAM, SSD и разделение ролей дает больше профита, чем попытка «дожать» систему на одном перегруженном инстансе.