Перейти к содержимому

Фотография

Jmeter. Вопрос по созданию нагрузки с равными интервалами между запрос

#Jmeter #Помощь #Производительность #Нагрузка #Интересный кейс #интервалы между запросами #приключения:-)

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 5

#1 ckrokis

ckrokis

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • ФИО:Зиганшин Максим
  • Город:Мытищи

Отправлено 21 мая 2018 - 20:27

Возник интересный вопрос по функциональности jmeter, а именно по такому вот кейсу:
 
Есть 4 последовательных запроса:
1) В первом происходит создание записи на сервере (метод POST)
2) Во втором получение данных по этой записи (метод GET)
3) В третьем и четвёртом делается апдейт записи (метод PATCH).
 
Второй запрос выполняется сразу после успешного выполнения первого, перед третьим запросом задержка +1 секунду, перед четвёртым запросом задержка +2 секунды. Но... первый запрос должен выполнятся раз в секунду и одновременно 160 "пользователями" (бизнес-требование такое - проверяем как будет вести себя система, если например в сети "просадка" не зависящая от нас возникнет и потом вдруг посыпятся запросы правильные, не ддос, или во внешних системах будет сбой и произойдёт такой сценарий - заранее отвечаю на вопрос зачем это надо, а то по), а ответ на него может идти до 10-15 секунд при нагрузке - можно ли с помощью инструмента Jmeter как то этого добиться?
 
Возможно, с помощью какого-нибудь контроллера/плагина можно 2, 3 и 4 запросы вынести и сделать так, что бы первый запрос не ждал завершения 2-го, 3-го и 4-го, а продолжал отправлять следующие запросы и при этом 2, 3 и 4 запросы просто позже, но при этом со всеми полученными в 1-ом запросе id'шниками (в режиме реального времени, а не так, что бы закончить первые запросы, взять готовый файл с ID'шниками и начать делать 2, 3 и 4 запросы)?
 
Пробовал много разных вариантов, неделю искал решение, но пока только отдалённое приближение сделать смог... Кто нибудь может подсказать решение?
 
P.S.: Частичное решение нашёл - https://jmeter-plugi...dCommunication/ просто перекинуть в другую Thread Group переменную и в ней выполнять 2, 3 и 4 запросы :-) правда когда заканчивает выполнятся цикл с первым запросом, то другая группа с 2, 3 и 4 запросами зависает или падает с ошибками, т.е. не все обрабатываются, похоже не хранятся данные для запросов, а берутся в режиме реального времени, без прихранивания id'шников, и значительная часть созданных на сервере записей первым запросом остаётся без обработки 2, 3 и 4 запросом...
 
Вот эта статья интересная, но немного не о том... http://software-test...acija-nagruzki/

  • 0

#2 fesd

fesd

    Опытный участник

  • Members
  • PipPipPipPip
  • 262 сообщений

Отправлено 21 мая 2018 - 20:52

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


  • 0

#3 ckrokis

ckrokis

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • ФИО:Зиганшин Максим
  • Город:Мытищи

Отправлено 21 мая 2018 - 21:23

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

Так дело в том, что при выполнении первого запроса получается в переменной id'шник, во втором треде начинают отрабатывать запросы с ним и когда они заканчивают отработку то в первой группе уже 2-3 id'шника в этой переменной поменяются (похоже не прихраниваются они), и надо что бы это всё вместе шло как бы, а не так что бы первый тред отработал и потом второй запустился, минут 10 работает и первый и второй одновременно примерно (второй можно немного позже запускать, что бы были готовые id'шники уже)

+ ещё тема с принудительной отправкой в первом треде запросов - вот есть там один-одинёшенек HTTP request создания записи на сервере (методом POST) в первом треде, отправляется он с интервалом в 1 секунду, но не после получения ответа, а так: первый раз отправили, второй раз отправили и так далее, и например после отправки 4-го или 5-го получаем ответ на первый... Такой возможности пока не нашёл...


  • 0

#4 ckrokis

ckrokis

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • ФИО:Зиганшин Максим
  • Город:Мытищи

Отправлено 21 мая 2018 - 21:24

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

Проблема в том, что эти 4 запроса должны как бы нагружать сервер вместе... пробовал записывать файл - вроде норм, но так что бы записывать его и извлекать в процессе теста данные пока не смог, а каким плагином лучше выуживать переменные из ответов? Перепробовал несколько разных, везде ситуация была такая, что не прихранивались id'шники - возможно надо добавить прослойку между тем плагином который id получает из ответов и межтредовым взаимодействием?...


  • 0

#5 Alex

Alex

    Постоянный участник

  • Members
  • PipPipPip
  • 237 сообщений
  • ФИО:Алексей

Отправлено 22 мая 2018 - 05:22

 

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

Проблема в том, что эти 4 запроса должны как бы нагружать сервер вместе... пробовал записывать файл - вроде норм, но так что бы записывать его и извлекать в процессе теста данные пока не смог, а каким плагином лучше выуживать переменные из ответов? Перепробовал несколько разных, везде ситуация была такая, что не прихранивались id'шники - возможно надо добавить прослойку между тем плагином который id получает из ответов и межтредовым взаимодействием?...

 

А у вас обработка запросов точно асинхронная? Если обработка синхронная, то отправлять каждую секунду при response time ~ 10-15 сек можно только путем использования 10-15 виртуальных пользователей (или заморачиваться с request/response timeout, но тогда у вас не будет response и технически операция будет failed). Чтобы поддерживать постоянную нагрузку в запросах в секунду стоит посмотреть в thread group/timers, которые настраиваются на определенную цель. Попробуйте почитать эту статью https://www.blazemet...-constant-timer.

В целом мне видится несколько некорректное решение поставленной задачи. Сделать как вы хотите можно, но это будет достаточно сложно, на мой взгляд. Проще, думаю, иметь две параллельные группы: одна шлет POST каждую секунду. Вторая просто генерирует нагрузку Get и Patch с заданной конфигурацией (чтобы параллельно проверять нагруженность сервера). Вам ведь без разницы на самом деле какие записи вы будете дергать через Get и обновлять через Patch. Просто выберите для этой группы существующие записи и поместите их в пул данных.


  • 0

#6 ckrokis

ckrokis

    Новый участник

  • Members
  • Pip
  • 5 сообщений
  • ФИО:Зиганшин Максим
  • Город:Мытищи

Отправлено 30 мая 2018 - 10:35

 

 

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

Проблема в том, что эти 4 запроса должны как бы нагружать сервер вместе... пробовал записывать файл - вроде норм, но так что бы записывать его и извлекать в процессе теста данные пока не смог, а каким плагином лучше выуживать переменные из ответов? Перепробовал несколько разных, везде ситуация была такая, что не прихранивались id'шники - возможно надо добавить прослойку между тем плагином который id получает из ответов и межтредовым взаимодействием?...

 

А у вас обработка запросов точно асинхронная? Если обработка синхронная, то отправлять каждую секунду при response time ~ 10-15 сек можно только путем использования 10-15 виртуальных пользователей (или заморачиваться с request/response timeout, но тогда у вас не будет response и технически операция будет failed). Чтобы поддерживать постоянную нагрузку в запросах в секунду стоит посмотреть в thread group/timers, которые настраиваются на определенную цель. Попробуйте почитать эту статью https://www.blazemet...-constant-timer.

В целом мне видится несколько некорректное решение поставленной задачи. Сделать как вы хотите можно, но это будет достаточно сложно, на мой взгляд. Проще, думаю, иметь две параллельные группы: одна шлет POST каждую секунду. Вторая просто генерирует нагрузку Get и Patch с заданной конфигурацией (чтобы параллельно проверять нагруженность сервера). Вам ведь без разницы на самом деле какие записи вы будете дергать через Get и обновлять через Patch. Просто выберите для этой группы существующие записи и поместите их в пул данных.

 

"А у вас обработка запросов точно асинхронная?" - не точно, это эксперимент :-) точнее поиск путей решения реализации такого типа нагрузки, сейчас кастомно-кастыльно делаю с помощью ultimate thread group на 5 минут тот кейс, который описан в начале (в одной группе, в одном Sample Controller все 4 запроса норм живут и работают), но хотелось бы его на подольше запускать, по этому продолжаю поиск путей решения, пока с jmeter.

Пример с ultimate thread group на скриншоте ниже:

 

Прикрепленный файл  2018.05.30_0001.jpg   36,28К   1 Количество загрузок:

 

"Вам ведь без разницы на самом деле какие записи вы будете дергать через Get и обновлять через Patch." - увы, нет, надо что бы проставлялись именно тем, кто был создан на серваке первым запросом, так сказать "полная имитация" деятельности пользователя на сайте.

 

"Попробуйте почитать эту статью https://www.blazemet...-constant-timer." - Почитал, спасибо :-) Там так и написано:

 

This timer allows us to keep total throughput constant. Of course, if the server is not able to handle such a load, the throughput will be lower.

Этот таймер позволяет нам поддерживать полную пропускную способность постоянной. Конечно, если сервер не способен обрабатывать такую ​​нагрузку, пропускная способность будет ниже.

 

А ответ на каждый запрос может идти как 500мс, так и 10000мс, так что не прокатывает, подробности ниже.

 

P.S.: Возможно, зря сразу стал описывать всю ситуацию целиком, думаю достаточно пока ответа на вопрос, как построить такой кейс на длительное время (касается первого запроса типа POST в более "щадящем", но длительном кейсе, а про запросы 2, 3 и 4 пока "забудем" и будем решать проблемы по мере их поступления):

 

Есть 6 юзеров/потоков, которые кидают на сервер 1 раз в секунду по 1 POST запросу каждый, при этом ответ на каждый запрос может идти как 500мс, так и 10000мс, так что вопрос с рассчётом стабильной нагрузки через количество юзеров отпадает (пробовал в самом начале).

 

Пробовал через таймеры со скриншота ниже:

 

Прикрепленный файл  2018.05.30_0002.jpg   33,8К   3 Количество загрузок:

 

Но у них есть "слабость" - ждут ответа от сервера, что бы послать запрос снова, а надо что бы раз в секунду посылался запрос каждым пользователем не дожидаясь ответа на предыдущий запрос, ну или как то ещё, что то вроде распараллеливания запросов юзера, но пока решения толкового с JMeter не нашёл... И решил обратится к знающим людям тут ;-)

  • 0



Темы с аналогичным тегами #Jmeter, #Помощь, #Производительность, #Нагрузка, #Интересный кейс, #интервалы между запросами, #приключения:-)

Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных