Как протестировать производительность приложения rails в рамках цикла непрерывной интеграции?

Question

В настоящее время мы используем CruiseControl (версия ruby) для CI, и он запускает наши модульные и интеграционные тесты (в основном, rspec).

Это замечательно: он дает нам мгновенную обратную связь по любым функциональным проблемам или регрессам (я использую instant в приблизительном смысле ;-).

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

Я бы хотел, чтобы наша сборка стала КРАСНОЙ, если тесты измеряют снижение производительности, скажем, 5% И, конечно, указывают нам на проблему, будь то плохо отвечающие запросы к базе данных, время, проведенное в функция ruby ​​или ответ контроллера.

Непрерывное тестирование производительности - тема, которая в течение последних нескольких лет была немного обсуждена, но, за исключением нескольких предложений поставщиков (в основном, направленных на мир Java и .NET), я не вижу особой стороны Rails. , Я думаю, что мы похожи на большинство: тестирование производительности, нагрузки и объема - это отдельное действие, обычно выполняемое перед серьезным обновлением, но часто забываемое во время рутинных итераций и выпусков. И мы избавляемся от серьезных неприятностей только из-за того, что NewRelic отлично следит за нашими живыми инстанциями, и благодаря удаче.

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

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

Answer 1

Предполагая, что вы уже видели это: http://guides.rubyonrails.org/performance_testing.html

С другой стороны, мы запускаем ночной тест производительности на основе Grinder через нашу инфраструктуру CI на основе Jenkins.Обратите внимание, что он запускается не для каждой сборки, он выполняется автоматически каждую ночь, захватывает последнюю сборку (то есть, может быть, каждые 4 сборки или около того). На выполнение тестов на различных уровнях одновременных пользователей уходит около 4 часов, но мы могли бы значительно сократить это время.если бы мы просто побежали на уровне одного пользователя.Поскольку он запускается через Jenkins, мы можем вернуть ошибку (сделать ее КРАСНОЙ), если метрики были плохими, но мы пока не делаем этого.

Если вы действительно просто ищете снижение производительности, вам следует выполнить один тест (который измеряет то, что вас волнует) для последнего кода и отследить то историческое время отклика от сборки до сборки.