У меня большой опыт работы с JMeter и JMH.Я бы сказал, что во многих случаях вы можете использовать любой из них, но в рамках тестирования производительности Java-класса только JMH действительно имеет значение , вы не сможете выполнить сравнительный анализ на уровне класса с JMeter, это будеттолько грубое приближение.Или это может сработать, если ваш класс выполняет длинные операции, где точность не так важна.Причины:
Собственные издержки JMeter являются значительными.Например, у меня есть тест JMH, который проверяет функцию X, и в среднем он составляет около 0,01 мс.Я также использую эту функцию в JMeter, чтобы настроить вещи в пользовательском семплере Java.Этот сэмплер обычно показывает среднее значение около 20 мс.Это в 200 раз больше, чем у JMeter.
С JMeter вы не можете избежать оптимизации JVM, которая делает эталонный тест практически нереальным (хотя из-за проблемы # 1 это может не иметь никакого значения).У JMH есть механизм, чтобы предотвратить эту ловушку.Я не думаю, что в JMeter вы можете решить эту проблему любым понятным способом.
Я также не согласен с мнением Дмитрия Т, что у него есть «Ограниченное количество режимов» - itна самом деле имеет более релевантные режимы, чем JMeter , и их проще настраивать:
- прежде всего он имеет несколько режимов, которые вы можете выбрать из (включая «время удержания»)Загрузка").Он также имеет возможность использовать все режимы одновременно (с отдельными результатами), поэтому вам не нужно выбирать один режим, и вы указываете это только с помощью аннотации или параметра командной строки.В JMeter это возможно только с дополнительной разработкой (например, отдельной группой потоков или тестом).
- JMH не имеет нарастания, но имеет разогрев, который позволяет исключить начальные исполнения из результата, таким образом, удостоверившись,результаты чисты от начального шума при запуске, который, по сути, является той же целью, что и увеличение
- , есть определенно способы управления итерациями: числом, их временем и т. д .;с помощью аннотации или командной строки.
Кроме того, в JMH есть несколько очень простых вещей, для которых в JMeter требуется множество различных обходных путей.Например:
- синхронизация итераций является вопросом аннотации в JMH, но потребует тщательной настройки в JMeter.
- асимметричный тест, который позволяет одновременно тестировать, например, модель производителя / потребителя, но измерять их независимо.В JMH вы пишете свои тесты, помечаете их аннотацией и все готово.В JMeter вам понадобятся значительные накладные расходы, чтобы настроить его правильно
С точки зрения отчетности, JMH, как и JMeter, имеет плагины для Jenkins и TeamCity, которые создают таблицы результатов и графики.Также он может публиковать результаты в различных форматах, которые могут быть использованы, обработаны или сохранены другими инструментами.
Так что, если JMH настолько хорош, то для чего хорош JMeter?
В основном для тестирования различных сетевых протоколов , хотя JMH не был создан для этого варианта использования.Именно здесь вы, вероятно, не заботитесь о затратах JMeter или оптимизации JVM, и можете воспользоваться встроенными сэмплерами в JMeter.Ничто не мешает вам тестировать любой сетевой протокол с JMH, конечно (при условии, что вы используете подходящую библиотеку).Но в JMeter вы освобождаетесь от написания пользовательского кода для обработки протоколов связи.
Вы не можете / не хотите писать код Java .В JMeter вы можете выразить свою логику визуально, что позволяет людям, которые не пишут код, писать тесты (хотя вам все еще может понадобиться управлять логикой теста с помощью некоторых концепций программирования, таких как циклы или таймеры, и вы можетенужно немного сценариев в предварительной / последующей обработке).Визуальная запись также может быть привлекательной, если вы можете использовать ее (то есть, если вы записываете тест HTTP).
Вы также можете почувствовать, что тесты JMeter находятся на «функциональном», в то время как тесты JMH находятся на «модульном» уровне тестирования.Но это весьма субъективно.