Автоматический регрессионный тест производительности во время выполнения в Java - PullRequest
Новая
       27

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

4 голосов
/ 20 января 2012

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

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

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

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

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

Ответы [ 3 ]

4 голосов
/ 22 ноября 2012

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

2 голосов
/ 21 января 2012

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

0 голосов
/ 20 января 2012

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

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

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

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

-

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

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

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

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

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

  1. Если Caliper собирает результаты, как получить результаты из Caliper, чтобы их можно было сохранить в произвольном формате.Документация калибра отсутствует.

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

...