Self-hosted трекер под нагрузкой: где серверы ломают ROI раньше, чем льётся трафик

Self-hosted трекер под нагрузкой: где серверы ломают ROI раньше, чем льётся трафик

У трекера узкое место обычно не в интерфейсе, а в цепочке записи событий: web → app → БД → постбэк. Если один слой начинает копить очередь, вы ловите лаг в отчётах, потери конверсий и ложные провалы в сплитах.

Что держать под контролем:
— CPU: пики часто дают не запросы к UI, а обработка постбэков и редиректов
— RAM: кеш и буферы важны, но утечки в демонах убивают стабильность
— I/O: медленный диск = задержка записи логов и роста очереди
— сеть: latency между трекером, БД и прокси влияет на TTL кук и точность атрибуции

Оптимизация начинается с разнесения ролей: трекер отдельно, БД отдельно, логи отдельно. Для горячих путей используйте быстрый storage, для архивов — холодный. Обязательно включайте ротацию логов и чистку мусора: раздувшийся диск ломает не только запись, но и резервное копирование. Чистим логи, проверяем постбэки.

Если нагрузка растёт, сначала смотрите не на «мощнее сервер», а на профиль запросов: где больше чтения, где больше записи, какие эндпоинты бьют по БД, а какие можно вынести в кеш. Data-driven подход или работа вслепую — выбор за тобой.