Jmeter. Вопрос по созданию нагрузки с равными интервалами между запрос
#1
Отправлено 21 мая 2018 - 20:27
#2
Отправлено 21 мая 2018 - 20:52
Решение с межтредовым взаимодействием мне видится правильным. Не понимаю только в чем у вас проблема. Что в очередь накидаете после запросов первого типа, то потом все и извлечете. Ничего не должно теряться.
#3
Отправлено 21 мая 2018 - 21:23
Решение с межтредовым взаимодействием мне видится правильным. Не понимаю только в чем у вас проблема. Что в очередь накидаете после запросов первого типа, то потом все и извлечете. Ничего не должно теряться.
Так дело в том, что при выполнении первого запроса получается в переменной id'шник, во втором треде начинают отрабатывать запросы с ним и когда они заканчивают отработку то в первой группе уже 2-3 id'шника в этой переменной поменяются (похоже не прихраниваются они), и надо что бы это всё вместе шло как бы, а не так что бы первый тред отработал и потом второй запустился, минут 10 работает и первый и второй одновременно примерно (второй можно немного позже запускать, что бы были готовые id'шники уже)
+ ещё тема с принудительной отправкой в первом треде запросов - вот есть там один-одинёшенек HTTP request создания записи на сервере (методом POST) в первом треде, отправляется он с интервалом в 1 секунду, но не после получения ответа, а так: первый раз отправили, второй раз отправили и так далее, и например после отправки 4-го или 5-го получаем ответ на первый... Такой возможности пока не нашёл...
#4
Отправлено 21 мая 2018 - 21:24
Решение с межтредовым взаимодействием мне видится правильным. Не понимаю только в чем у вас проблема. Что в очередь накидаете после запросов первого типа, то потом все и извлечете. Ничего не должно теряться.
Проблема в том, что эти 4 запроса должны как бы нагружать сервер вместе... пробовал записывать файл - вроде норм, но так что бы записывать его и извлекать в процессе теста данные пока не смог, а каким плагином лучше выуживать переменные из ответов? Перепробовал несколько разных, везде ситуация была такая, что не прихранивались id'шники - возможно надо добавить прослойку между тем плагином который id получает из ответов и межтредовым взаимодействием?...
#5
Отправлено 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. Просто выберите для этой группы существующие записи и поместите их в пул данных.
#6
Отправлено 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, #Помощь, #Производительность, #Нагрузка, #Интересный кейс, #интервалы между запросами, #приключения:-)
Тестирование →
Тестирование производительности →
JMeter - Тестирование производительности →
Можно ли в одной json extractor указать несколько переменных?Автор Slitha, 19 авг 2022 #jmeter |
|
|||
Работа и карьера →
Работа для тестировщика/QA →
Performance Testing Specialist (1 500 - 2 800 USD на руки)Автор IrinaDegtyareva, 09 авг 2021 #QA #Minsk, #Jmeter |
|
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных