Как отправить 4000+ запросов ровно через 1 секунду?

У меня есть HTTP GET request. Мне нужно отправить запрос на сервер приложений более чем за 4000 раз ровно через 1 секунду.

Я отправляю эти запросы с помощью JMeter. Я каждый раз принимал эфирные следы для каждого теста, используя инструмент сниффера (Wireshark).

Я попытался добиться этого с одной машины, нескольких машин (параллельно) и даже распределенного режима.

Собственно, результаты JMeter здесь не беспокоят. Забота этого теста заключается в том, чтобы увидеть, что запросы 4000 попадают на сервер за одну секунду в инструменте сниффера.

Я нашел почти 2500 запрос в 1 sec в эфирной трассе при использовании следующего плана тестирования JMeter.

Number of Threads= 4000
Ramp-Up Periods = 0 (Though it is depricated)
Loop count= 1

Когда я использую количество потоков в качестве 2500, я получил почти 2200 request, ударяя сервер за одну секунду в эфирной трассе.

Ответ от сервера для этого запроса здесь не касается. Я просто хочу убедиться, что запрос 4000, отправленный JMeter, попадает на сервер приложений за одну секунду.

UPDATE:

Случай 1: (4000 потоков)

Number of Threads= 4000
Ramp-Up Periods = 0 
Loop count= 1

Выход для случая 1:

JMeter (просмотр результатов в таблице): 2.225 секунд для запуска 4000 запросов.

Эфирная трассировка: 4.12 секунды для 4000 запросов на поражение сервера.

Случай 2: (3000 потоков)

JMeter (просмотр результатов в таблице): 1.83 секунды для запуска 3000 запросов.

Эфирная трассировка: 1,57 секунды для 3000 запросов на сервер.

Случай 3: (2500 потоков)

JMeter (просмотр результатов в таблице): 1.36 секунды, чтобы запустить 2500 запросов.

Эфирная трассировка: 2.37 секунды для 2500 запросов на сервер.

Случай 4: (2000 тем)

JMeter (просмотр результатов в таблице): 0,938 секунды, чтобы запустить 2000 запросов.

Эфирная трассировка: 1.031 секунд для 2000 запросов на поражение сервера.

I have run these test from only one machine. 
No listeners added.
Non-Gui mode.
No assertions in my scripts.
Heap size: 8GB

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

Так как 4000 потоков слишком тяжелые, возможно, мне нужно проверить это в режиме распределенного доступа. Я также пробовал с распределенным режимом (1 мастер, 2 подчиненных). Может быть, мой script ошибочен.

Можно ли увидеть в эфирной трассе, что мои 4000 запросов попали на сервер за 1 секунду?

Каким будет JMeter script для достижения этого сценария в распределенном режиме?

Ответ 1

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

Если у вас есть возвращающиеся пользователи и нет CDN, убедитесь, что ваша политика кэша хранится на клиенте, истекая с расписанием сборки. Это позволяет избежать повторных запросов от возвращающихся посетителей.
Если у вас нет возвращающихся пользователей и нет CDN, убедитесь, что в вашей политике кэширования установлено не менее 120% максимальной задержки страницы на страницу, отображаемой в ваших журналах для данного пользовательского набора.
Если у вас есть CDN, убедитесь, что все заголовки статических запросов, заголовки 301 и 404 настроены так, чтобы ваш CDN мог кэшировать ваши запросы до истечения срока с новым расписанием.
Если у вас нет CDN, рассмотрите модель, где вы размещаете все статические ресурсы на выделенном сервере, где все на этом сервере помечено для кэширования на клиенте на высоком уровне. Вы можете также фронт, что один сервер с лаком или кальмаром в качестве кэширующего прокси для загрузки

В общем, я бы заподозрил, что проблема дизайна в игре с этим высоким уровнем согласованного запроса. 4000 запросов в секунду составляют 14 400 000 запросов в час и 345 600 000 за 24 часа.

На основе процесса я также предложил бы минимум три генератора нагрузки: два для первичной нагрузки и один для виртуального пользователя управления одного виртуального пользователя | поток для вашего бизнес-процесса. В вашей текущей модели для всех на одном генераторе нагрузки у вас нет элемента управления для определения накладных расходов, вызванных потенциальной перегрузкой вашего генератора нагрузки. Использование элемента управления поможет вам определить, есть ли у вас генератор нагрузки, наведенный наклон в вашем движении нагрузки. По сути, у вас есть ресурс, из-за которого происходит перерыв скорости на вашем генераторе нагрузки. Пойдите для преднамеренной философии недогрузки на ваших генераторах нагрузки. Добавление другого генератора нагрузки дешевле, чем расход политического капитала, когда кто-то атакует ваш тест из-за отсутствия элемента управления, а затем вам нужно повторно запустить тест. Это также намного дешевле, чем преследование инженерного призрак, который появляется как медленная система, но который действительно является перегруженным генератором нагрузки.

Ответ 2

Вы хотите придерживаться JMeter? В противном случае Httperf является достойным инструментом и прост в использовании:

httperf --server=www.example.com --rate=4000 --num-conns=4000

например.

Надеюсь, это поможет немного, хотя и не полностью, о чем вы просили.

Ответ 3

Подумайте о том, чтобы разместить свой HTTP-запрос в Синхронизирующий таймер - таким образом вы будете уверены, что ваши запросы начинаются ровно в тот же момент.

Также потоки 4000 являются довольно "тяжелой" нагрузкой, поэтому я бы предложил следующие рекомендации 9 простых решений для теста загрузки JMeter "Out of Memory" Failure, чтобы получить максимальную отдачу от ваших экземпляров JMeter.

Ответ 4

Если вашего компьютера недостаточно, вы должны использовать распределенное тестирование в Jmeter
Имейте в виду, что теоретически вы можете отправлять 4000 запросов в секунду, они проведут некоторое время на пути к серверу, так что есть вероятность того, что они придут не через 1 секунду. Чтобы этого избежать, попробуйте для использования полосы пропускания с высокой пропускной способностью (например, вы можете разместить свой сервер в Azure облако и установить Jmeter в облаке тоже. )
Если у вас не будет успеха с JMeter, попробуйте использовать Tank инструмент, специализированный на высокой загрузке, и его можно отправить даже 10k запросов в 1 секунду от 1 машины.