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

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

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

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

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

Миф: Вы не можете запускать бенчмарки в CI

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

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

• Относительный бенчмаркинг
• Специализированные CI-runners
• Переход на другие системы бенчмаркинга, которые считают инструкции, а не системное время

Или просто примите этот хаос! Непрерывный бенчмаркинг не обязательно должен быть идеальным. Да, снижение волатильности и, следовательно, шума в вашей среде непрерывного бенчмаркинга позволит вам обнаруживать всё более тонкие регрессии производительности. Однако не позволяйте совершенству стать врагом хорошего здесь!

Вы можете посмотреть на этот график и подумать: “Вау, это безумие!” Но спросите себя, может ли ваш текущий процесс разработки выявить регрессию производительности на два, а то и на десять раз, прежде чем это повлияет на ваших пользователей? Вероятно, нет! Вот это действительно безумие!

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

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

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

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

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-хостами
• Пользовательская аутентификация и авторизация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот несколько функций, которые Bencher предлагает и которые инструменты APM не могут предложить:

• Обнаружение и предотвращение снижения производительности до его попадания в производство
• Изменения производительности и их влияние включены в кодовое рассмотрение
• Нет накладных расходов в производственной среде
• Эффективно для внутренних развертываний
• Никаких изменений в исходном коде производства

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

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

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

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

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

— Thoughworks Technology Radar, 22 May 2013

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

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

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

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

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