отчеты из JMeter

Здраствуйте,
Поделитесь опытом какие именно листнеры вы изпользуете в JMeter и какую полезную информацию для заказчика от туда можно выдернуть?
Если такая тема уже есть извините, не нашел.
Заранее благодарен.

В основном вот отсюда: http://code.google.c...jmeter-plugins/
Ну и еще по мелочи

В основном вот отсюда: http://code.google.c...jmeter-plugins/
Ну и еще по мелочи

Скажите, а чего еще не хватает в тех плагинах?

Скажите, а чего еще не хватает в тех плагинах?

Конкретно мне? Мне нужно было еще отдельные сервисы мерить. Но это особенности продукта. Пришлось немного дописывать.

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

... плагин от гугл кода ...

Это восхитительно :)

Давайте определимся с тем что вам надо. Вы тут спрашиваете какие именно градусники вам используем. Ок, мы привели пример. Потом вы продолжаете альше про то какие градусники используем. Тут уже пора переходить к вопросу "как", насколько я понимаю. Потому что любой градустник-листенер можно использовать... не очень корректно.

Давайте начнем с простого. Как вы измеряете? Что вы измеряете? Зачем вы измеряете именно это? Почему вы измеряете именно так? Что вас беспокоит в текущем вашем подходе?

В основном вот отсюда: http://code.google.c...jmeter-plugins/
Ну и еще по мелочи

Скажите, а чего еще не хватает в тех плагинах?

Действительно, не хватает измерения Servers Performance Monitoring для отдельного процесса. Хотя, как я понимаю у SIGAR есть такая возможность

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

Там я по линке что я дал у плагинчиков агенты можно на несколько серверов ставить.

Добавляю так же все остальные листнери из плагина ну и результат в таблице и дерево реультатов.

А это зачем? И я не понимаю какую смысловую нагрузку оно несет для вас. И вообще если вы хотите завалить заказчика статистикой это выдавать ему все данные это хороший подход. Но в других случаях они ему не нужны. Нужен ваш вывод. Кто у вас заказчик? Насколько он подкован технически?

Ну то есть у меня есть подозрение что вы не очень понимаете что конкретно хотите померить и мерить пытаетесь все и сразу. И я не понял как конкретно вы пытаетесь это мерить. То что задача определить предельную нагрузку я вроде как понял.

После беседы с Вами понял что я действительно плохо представляю что хочу и что надо.. И на том спасбо. Буду уточнять с заказчиком а потом копать мануалы. Спасибо за потраченное время!)

После беседы с Вами понял что я действительно плохо представляю что хочу и что надо.. И на том спасбо. Буду уточнять с заказчиком а потом копать мануалы. Спасибо за потраченное время!)

Мои 5 копеек: общение с заказчиком по-хорошему должно идти вокруг SLA. SLA - это ваша "линейка", которой меряют качество работы сервиса при массовой нагрузке. Хороший SLA формулируется из нескольких частей:
1. Требование времени обслуживания - "90% запросов должны обслуживаться в пределах 10 секунд". Проценты - потому что в массовой системе неизбежно будут нештатные ситуации и статистические выбросы. Требовать 100% обслужить вовремя - нонсенс. Тут мы также подходим к тому, что редко говорят в нагрузочном тестирование - оценка квантилями, а не средними.
2. Требование capacity - "система должна обслуживать в пределах п. 1 до 500 запросов в секунду".
3. Если на сервере пользователи висят подолгу и это оказывает свой эффект , то требование capacity номер 2 - "система должна поддерживать одновременную работу до 50 пользователей"
4. Еще можно сформулировать допустимый % ошибок, но это реже применяется.

И эта тема SLA очень важная. Если заказчик ее не формулирует так - попробуйте убедить его зафиксировать такой SLA и пересматривать по необходимости. Заказчику такие простые цифры будут очень хорошо понятны, вам будет легко ему рапортовать о состоянии системы. Если с заказчиком так не выходит - один фиг формулируйте для себя этот внутренний SLA и работайте относительно него. Будьте как взрослые!

А теперь мясо - как делать тесты, из которых получаются хорошие отчеты начальству:
1. Делайте тест на текущее состояние performance (т.е. как система работает "обычно") -
а) формулируем "обычную нагрузку" для системы (по логам продакшна или экспертным оценкам) и
б) делаем тест постоянной нагрузкой достаточной длительности.
в) измеряем для этого теста показатели - среднее время ответа ( , плохая оценка), квантили 50%-90%-95%-99% ( отличная оценка) и что там хочется еще. Заметим что железо нас тут интересует слабо (см. пункт 2).

2. Делайте stress-тест на capacity -
а) конфигурируем тест так, чтобы запросы в секунду/работающие юзеры нарастали линейно или ступенчато.
б) мониторим железо, времена ответа и долю ошибок
в) замечаем когда происходит первая точка перегиба - насыщение теста. это точка начала деградации показателей (времен ответа в первую очередь). тут обычно мы уже близко подходим к исчерпанию какого-то ресурса машины, но еще держимся в пределах SLA. лупим по серверу дальше!
г) точка нарушения SLA - мы уходим за пределы нормального обслуживания, но это не означает что система перестала работать. однако это наш предел нормального обслуживания. Тем не менее предположим что мы ЖЖшечка и на ДОСят и пока админы разгребают DDoS, мы пытаемся обслуживать дальше, как получится
д) точка отказа - сервис "затыкается", виснет по исчерпанию памяти, свитчи дымятся. Тут можно делать авто-стоп теста и фиксировать предельный capacity системы

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

Хэппи-энд.

Конечно упрощенная картина, но вроде достаточная для общения с руководством. Статья целая вышла :). Во многом она похожа на то, как делаем НТ мы в Яндексе.

APC, Спасибо большое. Полезная информация. Приму к сведению)

Мой совет к п.2 все же не смешивать в одну кучу запросы в секунду и количество работающих пользователей и делать разные тесты на рост этих показателей. Надо заметить что для разных систем заметны и полезны разные точки в-г-д, необязательно фиксировать прям все. Желательно всегда фиксировать г.

Кстати да, всегда было интересно... А что в данном случае имеется ввиду под работающими пользователями? Открытые коннекты? Живые пользователи умеют совершенно разную нагрузку создавать жеж. Я понимаю что нам это не сильно важно, но все же

Скажите, а чего еще не хватает в тех плагинах?

Раз возникла такая тема... Я немного про другое задам вопрос -- можно ли заменить плагином уже существующий в JMeter стандартный элемент?

Более конкретно -- мне не нравится, например, что XPath Extractor нельзя применять к существующей переменной (Regexp Extractor можно, а XPath Extractor нельзя). Я хочу использовать доработанную версию XPath Extractor. Но просто клонировать его и сделать ещё один, доработанный, не получается (особенности внутренней архитектуры JMeter, детали могу рассказать, если интересно). Поэтому нужно не новый добавить, а именно существующий заменить. Сейчас я патчу и пересобираю сам JMeter. А можно ли сделать плагин, который "вытесняет" и заменяет существующий элемент на альтернативный?

Кстати да, всегда было интересно... А что в данном случае имеется ввиду под работающими пользователями? Открытые коннекты? Живые пользователи умеют совершенно разную нагрузку создавать жеж. Я понимаю что нам это не сильно важно, но все же

:) Вот это отличная иллюстрация проблемы понимания области нагрузочного тестирования и достаточно важная. НТ в разрезе работающих пользователей надо стараться избегать, как огня . Насколько это возможно, нужно тестировать в разрезе запросов пользователей. Иначе встает проблема сэмулировать работу всего множества всех реальных пользователей, а это адъ .
Выход - использовать принцип "KISS" и разработать сценарий пользователя или нескольких пользователей, которых затем натравить на сервис, снять логи запросов и сравнить распределение запросов в реальных логах с тестовым. Подчеркиваю: задача - сэмулировать эквивалентный поток запросов, а не заниматься функциональными тестами.

Раз возникла такая тема... Я немного про другое задам вопрос -- можно ли заменить плагином уже существующий в JMeter стандартный элемент?

Более конкретно -- мне не нравится, например, что XPath Extractor нельзя применять к существующей переменной (Regexp Extractor можно, а XPath Extractor нельзя). Я хочу использовать доработанную версию XPath Extractor. Но просто клонировать его и сделать ещё один, доработанный, не получается (особенности внутренней архитектуры JMeter, детали могу рассказать, если интересно). Поэтому нужно не новый добавить, а именно существующий заменить. Сейчас я патчу и пересобираю сам JMeter. А можно ли сделать плагин, который "вытесняет" и заменяет существующий элемент на альтернативный?

Привет, Алексей!

Ну мы вообще в оффтопик уезжаем :)

Я заинтригован, что же такое не получается сделать с XPath Extractor :) Напиши мне подробней на проектное мыло, дело чести попытаться найти решение.

По поводу вытеснения в ЖМетре - а там даже их собственные модули все по схема плагинов идут, и можно выкинуть их все и работать только со своими, последним прошитым оплотом были Thread Group, но я их ликвидировал патчем. Конечно, там код тот еще спагетти и есть подводные грабли, но по части пост-процессоров мне казалось что все хорошо. Там надо хитро жонглировать иногда опциями видимости между тредами. В общем ты описывай задачу, я постараюсь помочь.

Выход - использовать принцип "KISS" и разработать сценарий пользователя или нескольких пользователей, которых затем натравить на сервис, снять логи запросов и сравнить распределение запросов в реальных логах с тестовым. Подчеркиваю: задача - сэмулировать эквивалентный поток запросов, а не заниматься функциональными тестами.

Тоже опа. Никто нам не гарантирует что пользователи в своей массе будут вести себя именно так. То есть можно подобрать частный случай когда именно так всю жисть и будет, но я бы не решился на таких проектах работать, например. Потому что в лучшем случае они стагнируют.
Особенно актуально снимать такие сценарии для еще не запущенных проектов. Не факт что наши бетатестеры (ну или как нам их назвать?) дадут нам репрезентативные сценарии. И вопрос в общем-то весьма серьезный, потому как релевантная картинка нагрузки на не запущенный сервис не сильно тривиально на мой взгляд. Как вы эти сценарии разрабатываете? Процедура в идеале не всем доступна) Особенно когда наш одинокий НТ сидит почти в изоляции.

Как вы эти сценарии разрабатываете? Процедура в идеале не всем доступна) Особенно когда наш одинокий НТ сидит почти в изоляции.

Не морочьте себе голову, берите продукционный лог запросов и лупите им. Или зафиксируйте свое видение типовой модели нагрузки и грузите ей. К черту сомнения, вы мужик или кто?!

Шучу. Когда сомневаетесь - сверяйте распределение из продукционных логов с распределением из тестовых, это раз. Еще следите за тем, как в продакшне ощущают себя ресурсы и времена ответа при нагрузке, такой же как в тесте. Похоже? Если нет, значит модель в чем-то неверна. Идеально не получится, ваши пассажи про то что "в реальности по-другому все" это от лукавого, то есть от функционального тестирования. Философский факт - тестовая среда, тестовые запросы и тестовые результаты всегда будут отличаться от продукционных. Штука в том, когда вы скажете что "уже достаточно похоже, good enough" и начнете не мычать начальству "Ну у нас конечно непохоже на реальность, но вроде новая версия лучше, но я сомневаюсь", а как мужик возьмете на себя ответственность за показатели нагрузочного тестирования и выдадите маленькую кучку цифр с подписями "10% лучше/хуже скорость, выдержим еще 150 посетителей в час".

И это не от имени Яндекса, это моя личная позиция.

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

Ну и про функциональное вы зря. Там тоже мычать про "ну в реальности может и не так и может мы не все нашли" лучше не стоит. За такое ящетаю надо "вон из профессии" говорить. Сказать "good enough" надо уметь везде. Как г-н Вейнберг писал: "Perfection is impossible to achieve. Trying to do the impossible will kill you".

UPD: Хотя если подумать, то варианта всего два: или делаем или нет. Наличие или отсутствие дополнительной информации это просто вопрос рисков. Хотелось бы очень добротно, да, но в жизни почему-то не всегда получается)