Основные метрики
- Латентность: медиана (p50), хвосты (p95, p99, p999). Например SLO — p99 < $100$ ms.
- Пропускная способность: запросов/сек (rps), транзакций/сек.
- Загруженность CPU: utilisation, user/sys, load average.
- Память: RSS, heap size, скорость аллокаций (alloc/sec), частота и паузы GC.
- Дисковый и сетевой I/O: IOPS, throughput (MB/s), задержки диска/сети.
- Контенция и блокировки: время ожидания mutex, очередь потоков.
- Апаратные счётчики: cache-misses, branch-mispredicts, cycles, CPI.
- Ошибки и ошибки по времени: rate ошибок, процент таймаутов.
- Бизнес‑метрики как комбинированный критерий (конверсии, время отклика, SLA).
Методы профилирования и инструменты
- Статистическая выборка (sampling profiler): периодические срезы стека; низкий оверхед, показывает горячие пути. Инструменты: perf, async-profiler, pprof.
- Инструментирование (instrumentation): замеры вход/выход функций, таймеры; точнее, но с большим оверхедом.
- Трейсинг распределённых систем: OpenTelemetry, Jaeger, Zipkin — даёт распределённые задержки и взаимосвязи сервисов.
- Flame graphs: визуализация горячих стэков из sampling — быстро локализуют узкие места.
- Профилирование памяти: heap profiler, allocation sampling (например, pprof heap, Java Flight Recorder).
- Анализ конкурентности: детекторы блокировок, lock profiling, thread contention tools.
- Низкоуровневые профайлеры: VTune, perf, oprofile для cache/branch/memory-bound проблем.
- Трассировка системных вызовов / I/O: strace, dtrace, eBPF (bcc, bpftrace), iostat, iotop, tcpdump.
- Нагрузочное тестирование / бенчмарки: wrk, k6, JMeter — для измерения throughput/latency под нагрузкой.
- Мониторинг и APM: Prometheus/Grafana, Datadog, NewRelic — для долгосрочного наблюдения и алертинга.
Практический рабочий процесс
1. Установить целевые SLO/SLA и метрики.
2. Собрать baseline (реальные трафик / воспроизводимая нагрузка).
3. Профилировать статистически → найти hotspot (функции/ресурсы).
4. Оценить вклад (скажем, функция занимает $30\%$ CPU).
5. Сначала алгоритмические/архитектурные улучшения, затем микрооптимизации.
6. Рефактор/оптимизация → регресс-тесты → нагрузочное тестирование → мониторинг в prod.
Пример, где микрооптимизация вредна
- Сценарий: функция, которая вызывается редко и занимает $0.1\%$ CPU общего времени. Разработчик вручную пишет сложный небезопасный код ради уменьшения нескольких тактов. Вред: ухудшается читаемость и поддерживаемость, повышается риск багов и уязвимостей, тестовое покрытие падает, а реальный выигрыш в производительности — пренебрежимо мал (например, экономия $0.1\%$ CPU). Вывод: не оптимизировать мелкие, незначимые участки прежде чем профиль покажет их критичность.
Пример, где микрооптимизация оправдана
- Сценарий: горячая петля в вычислительном ядре, выполняется $10^8$ итераций; одна итерация стоит $100$ ns, оптимизация уменьшает до $50$ ns. Экономия на всем прогоне: $(100-50)$ ns × $10^8$ = $5$ s — существенное улучшение. В real-time или high-frequency системах (аудио, HFT, рендеринг) даже десятки наносекунд на итерацию критичны. Здесь оправдана оптимизация на уровне инлайнинга, SIMD, уменьшения аллокаций.
Как выбирать, что оптимизировать
- Измеряйте: оптимизируйте то, что реально является бутылочным горлышком в вашем рабочем сценарии.
- Pareto / правило $80/20$: часто $20\%$ кода отвечает за $80\%$ времени; найдите эти $20\%$.
- Оценка выигрыша vs стоимость: потенциальная экономия времени/ресурсов × частота использования — затраты на разработку, риск и ухудшение читаемости.
- Приоритеты по SLA/SLO и бизнес‑метрикам: если p99 превышает лимит — фокус на уменьшении хвостовой латентности.
- Сначала алгоритмы и архитектура (изменить сложность $O(n)$→$O(\log n)$ даёт обычно больше, чем микрооптимизации). Используйте микро‑оптимизацию только после того, как: она измеренно полезна и альтернативы исчерпаны.
- Профилируйте в production‑like условиях; будьте внимательны к эффектах сборщика мусора, кэшам и параллелизму.
- Непрерывный мониторинг: после оптимизации следите за регрессиями и побочными эффектами.
Кратко: меряйте, ставьте цели, сначала алгоритмы/архитектуру, затем целевые микрооптимизации только для действительно горячих участков, контролируйте риск и читаемость кода.