TGViewer
about:performance about:performance @troubleperf · 1.5K subscribers
Post #99 5.75K
О бенчмаркинге, часть 1

Бенчмаркинг занимает значительную часть моей повседневной работы, поэтому важно понимать его основы, типы и ограничения.

По сути, это способ оценить производительность системы под нагрузкой.

Брендан Грегг в своё время ввёл наглядную терминологию: 
* Passive Benchmarking
* Active Benchmarking

———

Passive Benchmarking простой и распространённый подход: настраиваешь окружение, запускаешь нагрузку, получаешь на выходе цифры и в дальнейшем ими руководствуешься.

Но это как раз тот случай, когда «просто» не значит «лучше».

Проблемы таких замеров:
* риск измерить не то, что планировалось изначально
* непонятно, что именно ограничивает производительность
* нельзя отличить систематическое отклонение от шума (об этом позже)
* остаемся без ответа, почему получены именно такие результаты
* сами бенчмарки могут содержать баги, что останется от нас скрыто

«Бенчмаркаешь A, на самом деле измеряешь B, а выводы делаешь о C». ©


В итоге решения на основе таких данных могут оказаться даже хуже, чем если бы данных не было вовсе.

———

В противовес ему стоит Active Benchmarking (AB).

Помимо настройки окружения требуется активное наблюдение за системой во время прогона.

Задача понять:
* то ли мы меряем, что планировали
* что ограничивает производительность
* согласуется ли наблюдаемое поведение с нашей моделью системы
* что нужно изменить, чтобы улучшить результат

AB способен дать более надёжный результат.

Цена этого: более высокие требования к проведению эксперимента. Нужно не только уметь настроить окружение, но и верно интерпретировать наблюдаемое.

Алгоритм:
1. Собрать данные о работе системы, тулинг в помощь (perf, bcc, iostat, bpftrace, tcpdump, ...)
2. Интерпретировать, как реагирует система (методологии USE, RED, off-CPU, TSA, ...)
3. Применять в цикле:
запустил
└─ пронаблюдал
└─ сформулировал гипотезу во что упираемся
└─ проверил в следующем прогоне
└─ повторил


Каждый пункт по отдельности даёт ограниченный эффект, зато вместе позволяет быстрее и увереннее продвигаться вперёд.

———

Вывод

Сырые цифры от Passive Benchmarking могут выглядеть правдоподобно и при этом вести к неверным и дорогим решениям.

Слепо доверяясь им, мы фактически надеемся, что угадали с сетапом с первого раза и учли все нюансы.

Не похоже на надёжную стратегию

Active Benchmarking напротив, позволяет избежать ловушки «бенчмаркаешь A, измеряешь B, делаешь выводы о C».

Цифры, полученные таким методом, поддаются объяснению, их можно оспорить и воспроизвести.

И на них уже можно опираться при принятии инженерных решений.

———

Что почитать
- Active Benchmarking
- CPU Benchmarks and Bad Tinder Dates
- Performance Methodologies
- Producing Wrong Data Without Doing Anything Obviously Wrong (тут может помочь заметка о чтении white paper)

To be continued...

———

Поддержать лайком на Linkedin.
  • 🔥 12
  • 👍 6
  • ❤ 3
More from @troubleperf
  1. Aug 14, 2026Post #120
  2. Jul 12, 2026about:performance pinned «»
  3. Jul 12, 2026Post #118
  4. Jul 11, 2026Post #117
  5. Jul 5, 2026Про бенчмаркинг, часть 3 (части 1,2) Ранее обсудили, что борьба с шумом (noise) процесс бе…
  6. Jun 21, 2026Продублирую свой комментарий на вопрос: Стоит задача оценки достаточности мощности оборудо…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →