О бенчмаркинге, часть 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.

Аудитные логи в облаке — отдельная распределённая система со своими требованиями к надёжности и стоимости хранения, а не «таблица с событиями».

Команда MWS Cloud Platform выложила подробный разбор архитектуры своего сервиса: от библиотеки, которую подключают сервисы облака, до хранилища на Apache Iceberg и движка StarRocks, с объяснением, почему выбрали именно такой набор технологий и где спрятаны неочевидные грабли.

Полезно всем, кто разрабатывает ИБ-инструменты, работает с большим количеством событий или просто интересуется инструментами безопасности в облаке.

Читать статью на Хабре

⚠️ Хватит плодить хрупкие скрипты и оставлять дыры для троянов. Пора писать пуленепробиваемый инфраструктурный код.

🎥 Приглашаем на вебинар - Продвинутый Bash

На вебинаре вы узнаете:
- Связка set -euo pipefail навсегда исключит тихое проглатывание ошибок и потерю данных в конвейерах.
- Нативные подстановки Bash заменят тысячи ресурсоемких вызовов sed и сэкономят CPU.
- Регулярный мониторинг системных профилей защитит продакшен от перехвата команд троянами.
- Грамотный перехват сигналов через trap обеспечит безопасное сворачивание процессов при сбоях.

В результате вебинара вы:
- Замените многоуровневые костыли лаконичной логикой на базе ассоциативных массивов.
- Исключите утечки глобальных переменных через жесткую изоляцию областей видимости в функциях.
- Внедрите нативную построчную трассировку скриптов вместо примитивного дебага echo-принтами.
- Начнете напрямую пробрасывать переменные окружения в SystemD-юниты для надежного старта сервисов.

🧠 Открытый урок проходит в преддверии старта курса «Администратор Linux. Продвинутый уровень»

👉 Для участи зарегистрируйтесь: https://vk.cc/cYifdo

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru, erid: 2VtzqwQGMeg