Автоматический тест регрессии производительности Runtime в Java

Question

Я ищу способы автоматического обнаружения изменений во время выполнения моего кода. Это будет действовать аналогичным образом, что делает JUnit, но вместо проверки функциональности кода он будет испытывать внезапные изменения скорости. Насколько я знаю, сейчас нет инструментов для этого автоматически.

Итак, первый вопрос: Есть ли какие-либо инструменты, которые сделают это?

Тогда следующие вопросы: Если инструментов нет, и мне нужно сворачивать самостоятельно, каковы проблемы, которые необходимо решить?

Если второй вопрос актуален, то вот те вопросы, которые я вижу:

1. Изменчивость в зависимости от окружающей среды, она выполняется на.
2. Как обнаружить изменения, поскольку микро-тесты в Java имеют большую дисперсию.
3. Если калибр собирает результаты, как получить результаты из суппорта, чтобы они могли быть сохранены в пользовательском формате. Документация Caliber отсутствует.

Answer 1

Я не знаю, какие отдельные инструменты, чтобы справиться с этим, но JUnit имеет дополнительный параметр, называемый тайм-аут в @Test -annotation:

Второй необязательный параметр, тайм-аут, вызывает тест для отказа, если он занимает больше времени, чем указанное количество часов (измеряется в миллисекундах). Следующий тест не пройден:

@Test(timeout=100) public void infinity() { 
    while(true); 
} 

Таким образом, вы можете написать дополнительные юнит-тесты, чтобы проверить, что некоторые части работают «достаточно быстро». Конечно, вам нужно как-то сначала решить, какой максимальный период времени требуется для выполнения конкретной задачи.

-

Если второй вопрос актуален, то вот те вопросы, которые я см:

1. Изменчивость в зависимости от окружающей среды, она выполняется на.

Там всегда будет некоторая изменчивость, но свести его к минимуму, я бы использовал Хадсон или подобный автоматизированный тестовый сервер здания & для запуска тестов, так что среда будет такой же, каждый раз, когда (конечно, если сервер, на котором запущен Hudson, также выполняет все другие виды задач, эти другие задачи все равно могут повлиять на результаты). Вы должны принять это во внимание при определении максимального времени работы для тестов (оставьте «головную комнату», поэтому, если тест займет, скажем, 5% больше, чем обычно, он все равно не сгорит сразу) ,

1. Как обнаружить изменения, так как микро тесты в Java имеют большой разброс.

Microbenchmarks в Java редко надежны, я бы сказал, что тест больше ломти с интеграцией тестов (например, обработка один HTTP-запрос или то, что когда-либо у вас есть) и измерить общее время. Если тест завершился неудачно из-за слишком большого количества времени, изолируйте проблемный код путем профилирования или измерения и выключения времени выполнения отдельных частей теста во время тестового прогона, чтобы увидеть, какая часть занимает наибольшее время.

1. Если суппорт собирает результаты, как получить результаты из суппорта, так что они могут быть сохранены в пользовательском формате. Отсутствует документация Caliber's .

К сожалению, я ничего не знаю про суппорт.

Answer 2

Взгляните на Caliper CI, я выпустил версию 2.0 вчера как плагин Jenkins.

Answer 3

Я только что наткнулся на http://scalameter.github.io/, который выглядит подходящим, работает в scala и java.