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

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

У self-hosted трекера узкие места почти всегда одни и те же: CPU на разборе событий, диск на записи логов, БД на блокировках, сеть на постбэках. Если это не мониторить, вы видите не «падение конверсии», а потерю части событий в пайплайне.

Держите базовый чек-лист:
— выносите БД на отдельный диск/том с низкой latency;
— включайте индексы только под реальные запросы, иначе запись станет дороже чтения;
— очереди на постбэки и импорт конверсий отделяйте от веб-приёма;
— ставьте лимиты на воркеры, чтобы всплеск трафика не убивал весь процесс.

Для high-load важен не максимум ресурсов, а стабильная задержка. Трекер лучше переживает ровный поток, чем скачки: буферизация, асинхронная запись, batched inserts и короткие транзакции дают больше профита, чем «докинуть ещё CPU». Логи и метрики храните отдельно, иначе диагностика превращается в шум.

Проверяйте p95 latency по приёму клика и по отправке постбэка, а не только среднюю загрузку сервера. Если растёт очередь — сначала режьте лишние синхронные операции, потом масштабируйте железо. Чистим логи, проверяем постбэки.