VG
Size: a a a
2018 December 09
VG
KY
Сейчас в jmeter опечатаешься в имени переменной и никогда не поймёшь.
скрипты тоже надо дебажить :)
KY
есть assertion различные, используются не только чтобы понять что ответы валидные но и запросы удачные)
ВС
Assertions хорошая вещь.
В рекомендациях от JMeter говорится о том, что их должно быть немного:
Use as few Assertions as possible
https://jmeter.apache.org/usermanual/best-practices.html#lean_mean
В рекомендациях от JMeter говорится о том, что их должно быть немного:
Use as few Assertions as possible
https://jmeter.apache.org/usermanual/best-practices.html#lean_mean
ВС
Но всегда использую. Важно не забыть изменить поведение по умолчанию катушки (Action to be taken after a Sampler error) с Continue на Start Next Thread Loop
https://jmeter.apache.org/usermanual/component_reference.html#Thread_Group
https://jmeter.apache.org/usermanual/component_reference.html#Thread_Group
ВС
А после рефакторинга (переименования переменных) можно сделать поведением, даже - остановку теста при ошибках. Чтобы быстро разобрать ситуацию, найти источник, переименовать все корректно
KY
Привет.
Ответ на вопрос зависит от шага нагрузки и требуемой интенсивности. А также от сценария работы.
Если весь сценарий работы с сайтом укладывается в 30 сек, и нужна интенсивность лишь 2 сценария в минуту. То один пользователь успешно создаст такую нагрузку. И тогда достаточно одного пользователя.
Если же нужна большая интенсивность, и шаг другой. Пусть шаг 60 сек, и нужно 1000 операций в минуту, то значит потребуется минимум 1000 пользователей.
Подробнее по теме шага, интенсивности и пользователей в статье:
https://loadtestweb.wordpress.com/2017/08/23/pacing/
Ответ на вопрос зависит от шага нагрузки и требуемой интенсивности. А также от сценария работы.
Если весь сценарий работы с сайтом укладывается в 30 сек, и нужна интенсивность лишь 2 сценария в минуту. То один пользователь успешно создаст такую нагрузку. И тогда достаточно одного пользователя.
Если же нужна большая интенсивность, и шаг другой. Пусть шаг 60 сек, и нужно 1000 операций в минуту, то значит потребуется минимум 1000 пользователей.
Подробнее по теме шага, интенсивности и пользователей в статье:
https://loadtestweb.wordpress.com/2017/08/23/pacing/
KY
вот читал я эту годнейшую статью про то как сунуть в Jmeter фичу ЛР с пейсингами, на деле я решал ее Parallel Plugin. Делается так:
1. Мерим сколько по времени выполняется запрос.
2. Располагаем запрос на одном уровень параллельно с таймером внутри которое значение близкое к полученному из пункта 1
3. Внутри запроса кладем таймер непосредственно интенсивности, но за вычетом времени выполнения из пунткта 1.
Пример:
Запрос длится секнду и должен делаться раз в 1 мин.
Делаем первый таймер на секунду а внутренний на 59 сек.
Значения таймеров можно получать динамически и предыдущего треда, если время запроса сильно разное. Обычно хватает фиксированного значения.
1. Мерим сколько по времени выполняется запрос.
2. Располагаем запрос на одном уровень параллельно с таймером внутри которое значение близкое к полученному из пункта 1
3. Внутри запроса кладем таймер непосредственно интенсивности, но за вычетом времени выполнения из пунткта 1.
Пример:
Запрос длится секнду и должен делаться раз в 1 мин.
Делаем первый таймер на секунду а внутренний на 59 сек.
Значения таймеров можно получать динамически и предыдущего треда, если время запроса сильно разное. Обычно хватает фиксированного значения.
KY
Assertions хорошая вещь.
В рекомендациях от JMeter говорится о том, что их должно быть немного:
Use as few Assertions as possible
https://jmeter.apache.org/usermanual/best-practices.html#lean_mean
В рекомендациях от JMeter говорится о том, что их должно быть немного:
Use as few Assertions as possible
https://jmeter.apache.org/usermanual/best-practices.html#lean_mean
Стараюсь выстраивать процесс с помощью CI таким образом чтобы на низкой интенсивности сначала пробежал смоук текст с ассертейшеном а потом уже основной/целевой
KY
Но всегда использую. Важно не забыть изменить поведение по умолчанию катушки (Action to be taken after a Sampler error) с Continue на Start Next Thread Loop
https://jmeter.apache.org/usermanual/component_reference.html#Thread_Group
https://jmeter.apache.org/usermanual/component_reference.html#Thread_Group
Обычно я сам создаю тест экшн и им управляю тестом, я и забыл уж про то что эта настройка есть
KY
В моем гайде для динамического переиспользования времени ответа использую обычный пост процессор на JSR223 с языком Groovy (помню-помню почему работает быстрее всех) . JMeter итак хранит время выполнения в переменной нам нужна по сути сумма Load time, Connect, Time Latency
KY
Конечно не панацея зато без танцев с бубнами обмазыванием эксельниками и прочие прелести
KY
еще вот что откопал для любителей джавы http://grinder.sourceforge.net/
года 4 назад это было прям очень больно, если поддержки нет за эти сроки - не беритесь
VS
вот читал я эту годнейшую статью про то как сунуть в Jmeter фичу ЛР с пейсингами, на деле я решал ее Parallel Plugin. Делается так:
1. Мерим сколько по времени выполняется запрос.
2. Располагаем запрос на одном уровень параллельно с таймером внутри которое значение близкое к полученному из пункта 1
3. Внутри запроса кладем таймер непосредственно интенсивности, но за вычетом времени выполнения из пунткта 1.
Пример:
Запрос длится секнду и должен делаться раз в 1 мин.
Делаем первый таймер на секунду а внутренний на 59 сек.
Значения таймеров можно получать динамически и предыдущего треда, если время запроса сильно разное. Обычно хватает фиксированного значения.
1. Мерим сколько по времени выполняется запрос.
2. Располагаем запрос на одном уровень параллельно с таймером внутри которое значение близкое к полученному из пункта 1
3. Внутри запроса кладем таймер непосредственно интенсивности, но за вычетом времени выполнения из пунткта 1.
Пример:
Запрос длится секнду и должен делаться раз в 1 мин.
Делаем первый таймер на секунду а внутренний на 59 сек.
Значения таймеров можно получать динамически и предыдущего треда, если время запроса сильно разное. Обычно хватает фиксированного значения.
«а внутренний на 59сек»
А чем не устроит один единственный Precise Throughtput Timer в начале сценария с опцией «хочу ровно 1 запрос в секунду»?
Зачем что-то там вычислять?
А чем не устроит один единственный Precise Throughtput Timer в начале сценария с опцией «хочу ровно 1 запрос в секунду»?
Зачем что-то там вычислять?
KY
Превед. На работе тесты написаны на жметре 2 версии. Сейчас вроде 5 версия последняя? Надо ли при переходе со второй на пятую переписывать тесты, менять код скриптов и т.д? И есть ли в этом толк с практической точки зрения(код стал короче, шагов стало меньше, визуальнее стало лучше и т.д) ?
зависит от того че ты в скриптах, основные апдейты жметра это поддержка актуальной версии жавы. а нафичали там столько что скорее всего на большинство скриптов должно повлиять
KY
«а внутренний на 59сек»
А чем не устроит один единственный Precise Throughtput Timer в начале сценария с опцией «хочу ровно 1 запрос в секунду»?
Зачем что-то там вычислять?
А чем не устроит один единственный Precise Throughtput Timer в начале сценария с опцией «хочу ровно 1 запрос в секунду»?
Зачем что-то там вычислять?
он косячит на больших интенсивностях и наоборот очень низких
VS
он косячит на больших интенсивностях и наоборот очень низких
«большие интенсивности» это сколько?
«очень низкие» это сколько?
Как говорит Якубович: «Пример в студию!»
«очень низкие» это сколько?
Как говорит Якубович: «Пример в студию!»
VS
Косячит Constant Throughput Timer. А Preicse точно работает.
ВС
«большие интенсивности» это сколько?
«очень низкие» это сколько?
Как говорит Якубович: «Пример в студию!»
«очень низкие» это сколько?
Как говорит Якубович: «Пример в студию!»
На больших интенсивностях, вероятно, система под большой нагрузкой. И время работы выходит за размер шага нагрузки - превышает. Интенсивность снижается, ниже планируемой. Это не дефект CTT, это шаг недостаточно большой или запаса нет совсем.
Другой вариант - на больших интенсивностях много тредов в JMeter, так много, что им не хватает ни процессора ни памяти. JMeter тормозит по естественным причинам, подачи нагрузки снижается. И это не дефект CTT, это ресурсов не хватило. У всего есть пределы.
Другой вариант - на больших интенсивностях много тредов в JMeter, так много, что им не хватает ни процессора ни памяти. JMeter тормозит по естественным причинам, подачи нагрузки снижается. И это не дефект CTT, это ресурсов не хватило. У всего есть пределы.