Транспорт бэкенда
Бенчмаркинг транспорта: latency vs throughput
Twitter 2009: 'Fail Whale' появлялся каждые несколько часов. Инфраструктура не выдерживала нагрузки. Проблема была не в том что они не знали что сломано - они не умели измерять. Без правильных метрик (percentiles, flame graphs) невозможно найти bottleneck. Без capacity planning - невозможно не сломаться в момент пика.
- **LinkedIn** публично описал как perftool bechmarks помогли найти проблему в Kafka producer: P99.9 latency выросла с 2ms до 200ms из-за неправильного linger.ms. wrk2 выявил это, обычный wrk не показал.
- **Google** требует P99 SLO для каждого production сервиса. 'Error budgets': если P99 > target - команда тратит error budget и должна заморозить новые фичи до исправления.
- **Netflix** использует Gatling для load testing каждого deployment. Chaos Engineering (Chaos Monkey) дополняет - убивает инстансы в production для проверки resilience.
Latency vs Throughput: разные метрики
Latency (задержка) и throughput (пропускная способность) - разные метрики, часто с обратной зависимостью. Максимальный throughput достигается при высокой latency (батчинг, очереди). Минимальная latency - при низкой загрузке. Нельзя оптимизировать оба одновременно.
Jeff Dean (Google): latency хвосты убивают user experience. При 100 параллельных запросах к разным сервисам общая задержка = max(individual latencies). P99 одного сервиса * N параллельных сервисов = ужасный user experience.
Система при 70% загрузке имеет P99=15ms. При 90% - P99=300ms. Какой вывод?
Перцентили: P50, P95, P99, P99.9
P99 latency = значение такое, что 99% запросов обрабатываются быстрее. P99=100ms означает: 1 из 100 запросов медленнее 100ms. Среднее (mean) скрывает outliers - использовать его для SLO нельзя.
Gil Tene (Azul Systems): «Coordinated Omission» - классическая ошибка бенчмарков. Если система лагает, инструмент не отправляет следующий запрос пока не получит ответ - скрывая реальный tail latency. wrk2 и Gatling исправляют это через scheduled arrivals.
Mean latency = 10ms, P99 = 500ms. Какую метрику использовать для SLO?
Инструменты бенчмаркинга
Разные инструменты для разных протоколов: wrk/wrk2 для HTTP, ghz для gRPC, kafka-producer-perf-test для Kafka, pgbench для PostgreSQL. Ключевые параметры: concurrency, duration, request rate.
wrk vs wrk2: wrk измеряет throughput и считает latency 'как получится'. wrk2 сначала определяет максимальный throughput, затем запускает с фиксированным rate - это правильный способ измерить latency percentiles.
wrk показывает P99=5ms при 1000 req/s. wrk2 с тем же rate показывает P99=200ms. Почему разница?
Профилирование bottleneck
Бенчмарк показывает симптом, профилирование - причину. CPU bound vs I/O bound - разные решения. Flame graph визуализирует куда уходит CPU время. Network analysis (tcpdump) покажет задержки на сетевом уровне.
Brendan Gregg (Netflix, Meta) создал Flame Graphs и разработал USE Method (Utilization, Saturation, Errors) для системного анализа bottlenecks. Его книга 'Systems Performance' - стандарт для profiling Linux систем.
Flame graph показывает 60% времени в JSON.parse(). Следующий шаг:
Capacity Planning и SLO
Capacity planning - сколько серверов нужно для обеспечения SLO при ожидаемой нагрузке + headroom для burst. Основан на бенчмарках: сколько req/s даёт один инстанс при P99 < target latency.
Правило: держать utilization < 70% для предсказуемой latency. При 80%+ latency становится нестабильной. Google рекомендует планировать capacity на 130% от пиковой нагрузки.
Mean latency достаточна для мониторинга - если среднее хорошее, система работает нормально
Mean скрывает tail latency. P99=500ms при mean=10ms - реальная проблема для 1% пользователей
При 100 concurrent пользователях математически ожидается что каждую секунду хотя бы один видит P99 latency. Для часто посещаемых сервисов это постоянные жалобы от 1% активных пользователей.
Инстанс держит P99 < 100ms до 700 req/s. Ожидаемый пик: 3500 req/s. Сколько инстансов?
Итоги
- **Percentiles, не mean**: P99 показывает опыт худших 1% пользователей - именно это основа SLO. Mean скрывает tail latency.
- **wrk2, не wrk**: правильный бенчмаркинг с фиксированным rate eliminates coordinated omission и показывает реальные percentiles.
- **Utilization < 70%**: держать нагрузку ниже knee of curve - после 70% latency растёт нелинейно. Capacity = peak * 130% headroom.
Связанные темы
Бенчмаркинг измеряет эффективность оптимизаций из других уроков:
- Batching и Zero-Copy — Бенчмаркинг показывает измеримый эффект батчинга и сжатия - без измерений нельзя подтвердить оптимизацию
- Distributed Tracing — Трейсинг дополняет бенчмаркинг: benchmarks показывают aggregate latency, traces показывают где конкретно время теряется
Вопросы для размышления
- Как правильно выбрать workload для бенчмарка - синтетический тест или replay production трафика?
- Как coordinated omission влияет на результаты большинства production APM систем?
- При каких условиях добавление серверов не улучшит P99 latency?