Запуск бенчмарков - одна из наиболее сложных и ответственных задач в обеспечении качества программного обеспечения. Производительность - критически важный аспект многих проектов, и поэтому отслеживание изменений в скорости работы кода во времени позволяет вовремя обнаруживать регрессии и оптимизировать процессы. В мире CI/CD инструменты, такие как GitHub Actions, предлагают удобные и бесплатные облачные решения для автоматизации тестов, сборки и развертывания. Но насколько они подходят для выполнения бенчмарков? Можно ли достичь с помощью них точных, воспроизводимых и надёжных результатов? Этот вопрос требует детального анализа, особенно с учётом особенностей и ограничений облачных CI-сервисов. В отличие от специализированного аппаратного обеспечения, на котором обычно запускаются бенчмарк-тесты, CI-сервисы предоставляют виртуальные машины, которые выделяются динамически и работают на общих ресурсах.
Виртуальные машины обновляются и перезапускаются, при этом другие параллельные задачи на сервере могут влиять на производительность, создавая шум и помехи в измерениях. Поскольку бенчмаркинг требует строгого контроля над окружающей средой - от стабильной версии ОС до отсутствия фоновых процессов - общие характеристики CI-среды поначалу кажутся несовместимыми с этими требованиями. Тем не менее, в последнее время появляется всё больше подходов и методологий, которые позволяют использовать возможности GitHub Actions для запуска сравнительных тестов производительности - так называемого относительного бенчмаркинга. Вместо попыток получить абсолютные показатели производительности, которые сложно воспроизвести в облаке, ориентируются на сравнение результатов двух версий кода, запущенных на одном и том же сервере в рамках одного задания GitHub Actions. Такой подход значительно снижает влияние фонового шума, так как сопоставляются результаты пар, полученные в идентичных условиях.
Одним из ключевых инструментов на этом пути стал Airspeed Velocity (asv) - фреймворк, созданный для управления историей бенчмарков, их автоматического запуска и визуализации результатов. Asv поддерживает режим continuous, который позволяет последовательно запускать тесты для двух версий кода, перемежая их, что особенно важно для уменьшения систематической ошибки и учета колебаний системы. Хотя запуск полного цикла asv continuous может занимать значительное время, порядка двух часов, этот подход обеспечивает достаточную точность, необходимую для выявления регрессий производительности с порогом значимости в процентном соотношении. При тестировании стабильности данного метода на протяжении нескольких недель с одинаковыми версиями кода, исследователи обнаружили приемлемую погрешность. Среднее значение соотношения производительности стремилось к единице, а стандартное отклонение оставалось на уровне 5%.
Несмотря на отдельные выбросы, достигающие скоростей работы вне диапазона 0,5-1,4, метод показал чувствительность к регрессиям в скорости порядка 50% и выше, что для многих проектов оказывается более чем достаточным уровнем контроля. При этом процент ложноположительных срабатываний оставался низким, что делает такой вариант полезным для практического применения. Несмотря на успехи, длительность бенчмарк-тестов с использованием GitHub Actions остаётся тревожащим вопросом. Разработка методов оптимизации процесса ведется параллельно с развитием фреймворка. Ключевые направления - это отказ от интерливированных процессов и сокращение числа прогонов за счёт уменьшения повторов, что может существенно сократить время выполнения, но увеличивает риск получения неточных или шумных результатов.
Например, отказ от интерливирования последовательного чередования тестов между двумя коммитами позволил сократить время примерно на 16 минут, но вызвал удвоение количества ложноположительных срабатываний. Аналогичная ситуация наблюдается при запуске единственного прохода без повторений - время почти вдвое короче при условии примерно четверного увеличения ложных тревог. Это явная демонстрация trade-off, когда сокращение времени производится за счёт снижения надёжности получаемых данных. Существуют и другие способы улучшить скорость работы CI-бенчмарков без очевидных потерь в качестве. Использование ускорителей для управления пакетами, таких как mamba вместо conda, позволяет значительно уменьшить время установки зависимостей и настройки виртуальных окружений.
Кроме того, применение кэширования компиляции посредством ccache сокращает лишние пересборки неизменённых компонентов, что существенно ускоряет процесс для проектов с большими C-расширениями и библиотеками. Комбинированное использование этих подходов уменьшает общий средний расход времени на запуск бенчмарков до порядка полутора часов - вполне приемлемого показателя для сложных и всесторонних тестов. Другой важный аспект настройки процесса - оптимизация триггеров запуска GitHub Actions. Вместо запуска на каждое изменение кода или для каждого коммита, рекомендуется применять срабатывание по меткам (labels). Такой подход предоставляет разработчикам контроль за запуском ресурсоёмких задач, позволяя инициировать бенчмарки только по требованию при оценке конкретных изменений.
Это не только экономит вычислительные ресурсы и время, но и снижает шум в отчетах и уведомлениях для команды. Необходимо учитывать, что в интерфейсе GitHub Actions отображение статусов на панели сборок остаётся связанным с последним пушем в ветку, а метка, ставшая причиной запуска, может относиться к более раннему коммиту. Это не критический недостаток, но создает некоторую путаницу при мониторинге, требующую внимания при использовании данного подхода. В целом, несмотря на исходные ограничения платформы GitHub Actions, методы относительного бенчмаркинга демонстрируют жизнеспособность для проектов, которым важно отслеживать влияние изменений кода на производительность без больших затрат. Хотя продолжительность тестов и присутствие фонового шума не позволяют рассчитывать на абсолютную точность измерений, с помощью грамотной настройки инфраструктуры и подбора параметров запуска возможно достигать результатов, достаточных для обнаружения значимых регрессий и улучшений.
Использование GitHub Actions в таком качестве особенно актуально для открытых проектов, у которых нет ресурсов на организацию специализированного оборудования и персонала. Также автоматизация и интеграция с системой контроля версий обеспечивают прозрачность и воспроизводимость тестов. Дополнительно, генерация графиков и подробных отчётов на GitHub Pages расширяет возможности аналитики и снижения времени на оценку результатов для разработчиков и заинтересованных лиц. Будущие направления развития включают в себя дальнейшее ускорение компиляций и тестов, использование параллельных прогонов как средства фильтрации ложноположительных срабатываний, а также интеграцию с другими высокоуровневыми системами мониторинга производительности. При правильном подходе GitHub Actions становится эффективным инструментом в цепочке обеспечения качества, совмещая удобство, гибкость и доступность.
Подводя итог, можно утверждать, что GitHub Actions вполне подходит для запуска бенчмарков в режиме относительного сравнения, позволяющего контролировать производительность с принятой степенью точности. Это открывает новые возможности для автоматизации производительных тестов в облаке, снижая порог входа и упрощая управление процессами в современных проектах разработки программного обеспечения. .
