9 подписчиков

Поиск точек разладки (changepoint) это популярная задача в разных областях

4 марта4 мар

1 мин

Это канал про тестирование ПО, поэтому ограничимся поиском точек разладки при анализе результатов тестирования производительности. В отличие от функционального тестирования результаты тестов производительности нужно постоянно анализировать и выявлять причины отклонений результатов, в некоторых компаниях этим занимаются отдельные команды (Андрей Акиньшин работе такой команды целую книжку посвятил, рекомендую к прочтению). Но если выделенной команды нет, а тестировать производительность всё еще хочется, то можно использоваться математические методы для анализа результатов. Не буду рассказывать, что задача поиска точек разладки непростая, Андрей Акиньшин это уже сделал. Вместо этого расскажу как это сделали мы в Tarantool. Мы настроили запуск бенчмарков на выделенной машине со специальными настройками, все результаты, полученные от бенчмарков отправляли в InfluxDB и в графане можно было посмотреть результаты запуска бенчмарков на разных ветках и коммитах. В какой-то момент поняли, что см

Поиск точек разладки (changepoint) это популярная задача в разных областях. Это канал про тестирование ПО, поэтому ограничимся поиском точек разладки при анализе результатов тестирования производительности. В отличие от функционального тестирования результаты тестов производительности нужно постоянно анализировать и выявлять причины отклонений результатов, в некоторых компаниях этим занимаются отдельные команды (Андрей Акиньшин работе такой команды целую книжку посвятил, рекомендую к прочтению). Но если выделенной команды нет, а тестировать производительность всё еще хочется, то можно использоваться математические методы для анализа результатов. Не буду рассказывать, что задача поиска точек разладки непростая, Андрей Акиньшин это уже сделал. Вместо этого расскажу как это сделали мы в Tarantool.

Мы настроили запуск бенчмарков на выделенной машине со специальными настройками, все результаты, полученные от бенчмарков отправляли в InfluxDB и в графане можно было посмотреть результаты запуска бенчмарков на разных ветках и коммитах. В какой-то момент поняли, что смотреть каждый день на результаты тестов скучно и неинтересно, было бы здорово сделать автоматический анализ. На тот момент я нашел два проекта, которые могли бы помочь с этим: ruptures и hunter. Оба проекта написаны на Python, только первый больше библиотека для поиска точек разладки, а второй это законченный инструмент, который изначально разрабатывался в Datastax для поиска точек разладки в результатах бенчмарков. Я выбрал второй проект, сейчас он переехал в инкубатор Apache и называется Otava. Otava позволяет анализировать данные из различных источников (CSV files, PostgreSQL, BigQuery), настраивать степень отклонения при превышении которой сообщать о регрессии и т.д. Мы интегрировали Otava в Tarantool CI и Otava сообщает обо всех существенных отклонениях в результатах. Пока анализ работает в неблокирующем режиме, но возможно когда со временем мы переведем его в блокирущий режим, чтобы не мержить код, который заведомо приносит регрессии в производительности.

Про Apache Otava есть две публикации "Hunter: Using Change Point Detection to Hunt for Performance Regressions" и "8 Years of Optimizing Apache Otava: How disconnected open source developers took an algorithm from 𝑛3 to constant time".