Железо и бенчмарки

slimTDS намеренно лёгкий: один процесс FrankenPHP (worker-режим) плюс PostgreSQL. Ни Redis, ни очередей сообщений, ни отдельного пула PHP-FPM. Благодаря этому потребление ресурсов невелико, а требования к железу — скромные.

Минимальные требования

Ресурс	Минимум	Рекомендуется
CPU	1 vCPU	2–4 vCPU
RAM	1 ГБ	2–4 ГБ
Диск	10 ГБ SSD	20+ ГБ SSD (см. хранение)
ОС	Linux с Docker + Docker Compose	то же
PostgreSQL	18 (входит в Compose)	18

На 1 ГБ RAM уменьшите число воркеров FrankenPHP (num в Caddyfile) примерно до 2 и следите за shared_buffers в PostgreSQL. 2 ГБ дают комфортный запас для стандартных 8 воркеров.

Диск и хранение

Основной потребитель диска — база данных, и она растёт вместе с трафиком:

• stats.clicks — одна строка на клик (RANGE-партиционирование по месяцам, индекс BRIN).
• stats.pixel_events — одна строка на событие пикселя (партиционируется).
• stats.rrweb_chunks — записи реплеев сессий, если они включены. Это самый крупный потребитель — порядка ~0,5 ГБ/день при умеренном трафике.

Партиции ротируются помесячно, а старые удаляются за пределами окна хранения (крон partitions:rotate). Если включаете реплеи сессий, закладывайте диск под объём записей или сокращайте срок хранения.

Бенчмарки

Методика

• Железо: VPS 4 vCPU / 16 ГБ, PostgreSQL 18.
• Сервер: FrankenPHP worker-режим, 8 воркеров.
• Инструмент: wrk, keep-alive соединения, реальный браузерный User-Agent.
• Эндпоинт: горячий путь движка GET /<slug>, который прогоняет весь конвейер — резолв посетителя, GeoIP, детект ботов, детект устройства, матчинг флоу и логирование клика (один INSERT на запрос).
• Оговорка: генератор нагрузки работал на том же хосте и конкурировал с сервером за CPU. На выделенной машине цифры выше — считайте это консервативной нижней границей.

Результаты (worker-режим)

Конкурентность	Пропускная способность	p50	p90	p99
20	~610 req/s	32 мс	42 мс	57 мс
50	~635 req/s	76 мс	91 мс	122 мс

Пропускная способность выходит на плато около 635 req/s при насыщенном хосте (и генераторе нагрузки на нём же). Это примерно 50 миллионов кликов/день запаса на небольшом 4-ядерном VPS — для полного конвейера, включая запись клика в базу.

Куда уходит время

PostgreSQL — не узкое место: суммарное время базы около 1,4 мс на запрос (INSERT клика ~0,8 мс). Всё остальное — PHP: роутинг плюс конвейер движка, обслуживаемые из «тёплого» воркер-процесса.

Убедитесь, что worker-режим включён

Worker-режим FrankenPHP инициализирует приложение один раз и переиспользует его между запросами. Классический режим (полная инициализация на каждый запрос) примерно в 25× медленнее на том же железе — около 24 req/s против ~635 req/s в наших тестах. Поле worker в каждом Caddyfile должно указывать на скрипт, который отдаёт php_server (public/index.php); см. Развёртывание.

Запусти сам

В комплекте slimTDS есть помощник для бенчмарка. Подними стек (make up) и укажи слаг любой активной кампании:

make benchmark SLUG=your-slug
# настроить нагрузку:
CONNS=100 DURATION=30s make benchmark SLUG=your-slug

Он запускает нагрузочный тестер fortio во временном контейнере — ставить ничего не нужно, а образ мультиарх, так что работает и на Apple Silicon, и на amd64-серверах. Бьёт в горячий путь движка и печатает пропускную способность, перцентили задержки и разбивку по кодам ответа:

Throughput : 2416.1 qps
Latency percentiles:
  p50%      6.36 ms
  p90%     14.30 ms
  p99%     23.24 ms

Осторожно

Каждый запрос пишет клик в stats.clicks, поэтому бенчмарь dev/staging-инстанс или одноразовый слаг, а не боевой money-path. И убедись, что включён worker mode, иначе меряешь bootstrap на каждый запрос, а не сам движок.