Что такое непрерывный бенчмаркинг?

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

К настоящему моменту все в индустрии программного обеспечения знают о непрерывной интеграции (CI). На фундаментальном уровне CI — это обнаружение и предотвращение регрессий функциональности программного обеспечения до того, как они попадут в продакшн. Аналогично, непрерывный бенчмаркинг (CB) — это обнаружение и предотвращение регрессий производительности программного обеспечения до того, как они попадут в продакшн. По тем же причинам, по которым юнит-тесты запускаются в CI при каждом изменении кода, тесты производительности должны запускаться в CB при каждом изменении кода. Эта аналогия настолько уместна, что первый абзац этого раздела — лишь «Mad Libs»-версия введения Мартина Фаулера в непрерывную интеграцию 2006 года.

🐰 Баги производительности — это баги!

Бенчмаркинг в CI

Миф: В CI нельзя запускать бенчмарки

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

Есть несколько способов справиться с этим:

1. Выделенные раннеры на физическом железе
2. Относительный непрерывный бенчмаркинг
3. Переход на инструменты бенчмаркинга, которые считают инструкции вместо настенного времени

Безусловно, выделенные раннеры на физическом железе — лучший вариант практически в любом случае. Bencher предлагает выделенные раннеры на физическом железе с разбросом менее 2%. Сравните это с раннерами GitHub Actions, где разброс между запусками может превышать 30%. Снижение волатильности, а значит и шума в вашей среде непрерывного бенчмаркинга, позволит вам обнаруживать всё более тонкие регрессии производительности.

Производительность имеет значение

Миф: Вы не заметите 100 мс задержки

Часто можно услышать утверждение, что люди не способны воспринимать 100 мс задержки. В поддержку этого утверждения обычно цитируют статью Nielsen Group о времени отклика.

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

— Якоб Нильсен, 1 января 1993

Но это попросту не так. В некоторых задачах люди способны воспринимать всего лишь 2 мс задержки. Лёгкий способ это доказать — эксперимент Дэна Лу: откройте терминал и выполните sleep 0; echo "ping", а затем sleep 0.1; echo "pong". Вы же заметили разницу‽

Ещё один распространённый источник путаницы — различие между восприятием задержки и временем реакции человека. Хотя на ответ на визуальный стимул уходит около 200 мс, это никак не связано с восприятием самого события. По аналогии, вы можете заметить, что ваш поезд опаздывает на две минуты (воспринимаемая задержка), даже если сама поездка занимает два часа (время реакции).

Производительность имеет значение! Производительность — это фича!

• Каждые 100 мс быстрее → на 1% больше конверсий (Mobify, что приносит +380 000 $/год)
• На 50% быстрее → на 12% больше продаж (AutoAnything)
• На 20% быстрее → на 10% больше конверсий (Furniture Village)
• На 40% быстрее → на 15% больше регистраций (Pinterest)
• На 850 мс быстрее → на 7% больше конверсий (COOK)
• Каждая секунда медленнее → на 10% меньше пользователей (BBC)

С угасанием закона Мура рабочие нагрузки, которые можно выполнять параллельно, придётся распараллеливать. Однако большинство нагрузок должны выполняться последовательно, и простое наращивание вычислительных ресурсов быстро становится неподъёмным и дорогим решением.

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

Инструменты для непрерывного бенчмаркинга

Прежде чем создать Bencher, мы отправились на поиски инструмента, который мог бы:

• Запускать бенчмарки на одном и том же физическом железе как локально, так и в CI
• Отслеживать бенчмарки на нескольких языках программирования
• Без проблем принимать вывод стандартных инструментов бенчмаркинга языка
• Быть расширяемым под вывод пользовательских инструментов бенчмаркинга
• Быть с открытым исходным кодом и поддерживать самостоятельный хостинг
• Работать с несколькими хостами CI
• Поддерживать аутентификацию и авторизацию пользователей

К сожалению, ничего, что удовлетворяло бы всем этим критериям, не существовало. Смотрите предшественников с исчерпывающим списком существующих инструментов бенчмаркинга, от которых мы черпали вдохновение.

Непрерывный бенчмаркинг за пределами CI

CI должен быть финальной проверкой, а не единственным местом, где проводятся тесты. Bencher — первый инструмент непрерывного бенчмаркинга, который позволяет запускать бенчмарки на одном и том же физическом железе как локально, так и в CI. Это даёт разработчикам и агентам возможность сравнивать свою локальную работу в процессе с любой точкой истории производительности проекта.

При запуске на локальном оборудовании Bencher на физическом железе позволяет продолжать многозадачность. Не нужно останавливать всё остальное в системе, выкачивать старую ветку и запускать сравнение.

При запуске в облачной среде Bencher на физическом железе позволяет доверять результатам. Можно не беспокоиться о шумных соседях, троттлинге или подменах хоста посреди теста.

Непрерывный бенчмаркинг в Big Tech

Инструменты вроде Bencher разрабатывались внутри Microsoft, Facebook (ныне Meta), Apple, Amazon, Netflix и Google, среди бесчисленного множества других компаний. Будучи титанами индустрии, они понимают важность мониторинга производительности во время разработки и встраивания этих наблюдений в процесс разработки через непрерывный бенчмаркинг. Мы создали Bencher, чтобы вынести непрерывный бенчмаркинг из-за стен Big Tech в сообщество open source. Ссылки на публикации о непрерывном бенчмаркинге из Big Tech смотрите в разделе предшественники.

Bencher: Непрерывное тестирование производительности

Bencher - это набор инструментов для непрерывного тестирования производительности. Когда-нибудь регрессия производительности влияла на ваших пользователей? Bencher мог бы предотвратить это. Bencher позволяет вам обнаруживать и предотвращать регрессии производительности до того, как они будут слиты.

• Запустить: Запустите свои тесты производительности локально или в CI, используя точно те же самые bare metal раннеры и ваши любимые инструменты для тестирования. CLI bencher оркестрирует запуск ваших тестов производительности на bare metal и сохраняет их результаты.
• Отслеживать: Отслеживайте результаты ваших тестов производительности со временем. Мониторите, запрашивайте и строите графики результатов с помощью веб-консоли Bencher на основе ветки исходного кода, испытательного стенда и меры.
• Поймать: Отлавливайте регрессии производительности локально или в CI, используя точно то же самое bare metal оборудование. Bencher использует инструменты аналитики, работающие по последнему слову техники, чтобы обнаружить регрессии производительности, прежде чем они будут слиты.

По тем же причинам, по которым модульные тесты запускаются, чтобы предотвратить регрессии функций, тесты производительности должны быть запущены с Bencher, чтобы предотвратить регрессии производительности. Ошибки производительности – это тоже ошибки!

Начните отлавливать регрессии производительности — попробуйте Bencher Cloud бесплатно.

Непрерывный бенчмаркинг против локального сравнения бенчмарков

Существует несколько инструментов бенчмаркинга, позволяющих сравнивать результаты локально. Локальное сравнение отлично подходит для быстрой итерации при настройке производительности. Однако на него не стоит полагаться для постоянного обнаружения регрессий производительности. Так же как возможность запускать юнит-тесты локально не отменяет необходимость в CI, возможность запускать и сравнивать бенчмарки локально не отменяет необходимость в непрерывном бенчмаркинге.

Bencher предоставляет ряд возможностей, которых нет у локальных инструментов сравнения бенчмарков:

• Сравнение одного и того же бенчмарка на разных тестовых стендах
• Сравнение бенчмарков между языками и инструментами
• Совместная работа и обмен результатами бенчмарков
• Запуск бенчмарков на выделенных тестовых стендах для минимизации шума
• Больше никакого копипаста

Непрерывный бенчмаркинг против управления производительностью приложений (APM)

Управление производительностью приложений (APM) — жизненно важный инструмент для современных программных сервисов. Однако APM рассчитан на использование в продакшене. К моменту обнаружения регрессии производительности она уже влияет на ваших клиентов.

Большинство дефектов в итоге обходятся дороже, чем обошлось бы их предотвращение. Дефекты дороги, когда они случаются, — как из-за прямых затрат на их устранение, так и из-за косвенных затрат из-за испорченных отношений, потерянного бизнеса и потерянного времени на разработку.

— Кент Бек, Extreme Programming Explained

Bencher предоставляет ряд возможностей, которых нет у инструментов APM:

• Отлавливание регрессий производительности до их слияния
• Изменения производительности и их влияние включаются в ревью кода
• Никаких накладных расходов в продакшен-средах
• Эффективно для локальных (on-prem) развёртываний
• Никаких изменений в продакшен-коде

Непрерывный бенчмаркинг против наблюдаемости

Роза под любым другим именем пахла бы так же сладко. См. Непрерывный бенчмаркинг против управления производительностью приложений выше.

Непрерывный бенчмаркинг против непрерывной интеграции (CI)

Непрерывный бенчмаркинг (CB) дополняет непрерывную интеграцию (CI). По тем же причинам, по которым юнит-тесты запускаются в CI при каждом изменении кода, тесты производительности должны запускаться в CB при каждом изменении кода.

Хотя юнит-тестирование и приёмочное тестирование широко признаны стандартными практиками разработки, эта тенденция не распространилась на область тестирования производительности. В настоящее время распространённые инструменты подталкивают тестировщиков к созданию одноразового кода и мышлению «нажать и заскриптовать». Отношение к тестированию производительности как к полноправному члену позволяет создавать более качественные тесты, покрывающие больше функциональности, что ведёт к лучшим инструментам для создания и запуска тестов производительности, и в итоге к тестовому набору, который можно сопровождать и тестировать.

— Thoughworks Technology Radar, 22 мая 2013

Непрерывный бенчмаркинг против непрерывного нагрузочного тестирования

Чтобы понять разницу между непрерывным бенчмаркингом и непрерывным нагрузочным тестированием, нужно понимать разницу между бенчмаркингом и нагрузочным тестированием.

Бенчмаркинг позволяет тестировать производительность программного обеспечения от уровня функции (микро-бенчмарки) вплоть до уровня сервиса (макро-бенчмарки). Бенчмарки отлично подходят для тестирования производительности конкретной части вашего кода в изолированных условиях. Нагрузочное тестирование проверяет производительность программного обеспечения только на уровне сервиса и имитирует множество одновременных пользователей. Нагрузочные тесты отлично подходят для тестирования производительности всего сервиса при определённой нагрузке.

🍦 Представьте, что мы хотим отслеживать производительность фургончика с мороженым. Бенчмаркинг можно использовать, чтобы измерить, сколько времени уходит на то, чтобы положить шарик мороженого в рожок (микро-бенчмарк), а также бенчмаркинг можно использовать, чтобы измерить, сколько времени требуется одному клиенту, чтобы сделать заказ, получить своё мороженое и расплатиться (макро-бенчмарк). Нагрузочное тестирование можно использовать, чтобы проверить, насколько хорошо фургончик с мороженым обслуживает 100 клиентов в жаркий летний день.

Продолжайте: Быстрый старт ➡