Точные тесты производительности измерения в средах - PullRequest
Новая
       7

Точные тесты производительности измерения в средах

2 голосов
/ 02 февраля 2012

Я использую Java в этом вопросе, но это действительно относится ко всем современным разработкам приложений.Наш «конвейер среды», как и многие из них, выглядит следующим образом:

  • Песочница для разработчиков
  • Непрерывная интеграция и тестирование
  • QA / Staging
  • Производство

Аппаратное обеспечение, доступный ОЗУ и ЦП в каждой из этих сред различны: мой ноутбук представляет собой двухъядерный Windows-компьютер объемом 2 ГБ.Тестирование выполняется на машине 4 ГБ.Производство - это два (с балансировкой нагрузки) 8-гигабайтных четырехъядерных сервера.

Очевидно, что один и тот же код будет работать по-разному при работе на этих разных машинах (средах).

Я думал о написанииавтоматические тесты производительности для некоторых из моих классов, которые будут иметь вид: 

private static final long MAX_TIME = 8000;

@Test
public final void perfTestSomething() {
    long start = System.currentTimeInMillis();

    // Run the test

    long end = System.currentTimeInMillis();

    assertTrue((end - start) < MAX_TIME);
}

Таким образом, автоматический тест производительности не выполняется, если тест занимает, скажем, более 8 секунд.

Но затем меня осенило, что код будет работать по-разному в разных средах и работать по-разному в зависимости от состояния JVM и GC.Я мог бы выполнить один и тот же тест 1000 раз на своей машине и получить совершенно разные результаты.

Поэтому я спрашиваю: как можно точно / надежно определять и оценивать автоматизированные тесты производительности при продвижении кода из одной среды в другую??

Заранее спасибо!

Ответы [ 2 ]

1 голос
/ 02 февраля 2012

Может случиться так, что вы хотите запускать тесты производительности только в определенном месте, которое более строго контролируется.Вам не обязательно запускать их во всех средах, в этом мало пользы.Вы должны запускать их в среде, наиболее близко имитирующей производственную конфигурацию (это то, что вас ДЕЙСТВИТЕЛЬНО волнует, верно?).

Кроме того, убедитесь, что вы ограничиваете себя в производительности.Не блокируйте их чуть выше того, что ваш сервер делает сейчас.Выберите некоторые разумные пороги, чтобы учесть некоторые изменения в текущем прогоне.

В долгосрочной перспективе мне показалось, что более полезным является график с показателями производительности.Не жесткий предел.Таким образом, мы можем наблюдать тренды различных функций с течением времени и атаковать их, когда они имеют слишком высокие тренды.

1 голос
/ 02 февраля 2012

Я мог бы выполнить один и тот же тест 1000 раз на своей машине и получить совершенно разные результаты.

На самом деле это маловероятно. Конечно, будет некоторая изменчивость, но если машина не будет загружена другими задачами, большинство из 1000 моментов времени будут довольно близко друг к другу.

Один из способов получения значимых - и стабильных - чисел состоит в том, чтобы запустить тест много раз, а затем посмотреть на определенные процентили временных интервалов (например, медиана, 90-й процентиль, 99-й и т.д.).

Существуют дополнительные сложности, которые возникают, если единица вашего тестирования меньше, чем один вызов JVM (скажем, вы тестируете один метод или группу связанных методов). Если это так, я настоятельно рекомендую прочитать Как написать корректный микропроцесс в Java?

...