Публикации
Мужчина
Решение с межтредовым взаимодействием мне видится правильным. Не понимаю только в чем у вас проблема. Что в очередь накидаете после запросов первого типа, то потом все и извлечете. Ничего не должно теряться.
Проблема в том, что эти 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 Количество загрузок:
