Как добиться стабильной пропускной способности с помощью группы потоков Jmeter и Concurrency

Мы пытаемся провести стресс-тестирование нашей системы с помощью Jmeter и столкнулись с непостоянной пропускной способностью, поэтому мы установили плагин Jmeter Concurrency Thread Group с Таймером формирования пропускной способности. В настоящее время мы запускаем его на одной конечной точке, чтобы обеспечить стабильную пропускную способность. мы устанавливаем:

  • Таймер формирования пропускной способности до 30 RPS в течение 60 секунд, область действия которого находится непосредственно в группе потоков параллелизма.

  • Целевой параллелизм, используя функцию tstFeedback как tstFeedback(tst,13,50,10), поскольку максимальное время отклика составляло около 1000

мы изначально достигли ожидаемого RPS, каждый раз, когда мы пытались выполнить тест, он приближался к 30 RPS:

Однако через пару часов без изменений в конфигурации или системе число запросов в секунду больше не достигало ожидаемого, и мы постоянно получали более низкие значения числа запросов в секунду (в диапазоне от 20 до 27 запросов в секунду):

Мы попытались увеличить Target Concurrency, но это не повлияло на количество запросов в секунду, и оно постоянно было меньше ожидаемого. Мы попытались сделать это, используя GUI и CLI с локального компьютера и CLI на удаленном экземпляре с установленным Jmeter, мы запускаем последнюю версию Jmeter (на данный момент 5.5) локально и на удаленном экземпляре, но это не имеет значения:

Увеличение HEAP также не имело значения

Когда мы увеличили уровень ведения журнала на локальном компьютере для диагностики проблемы, эта ошибка часто появлялась:

o.a.j.p.h.s.HTTPHC4Impl: IOException
java.net.SocketException: Socket closed

Характеристики тестового экземпляра

  • Удаленный экземпляр настроен на экземпляре AWS m6i.8xlarge.
  • Локальная машина имеет 16 ГБ памяти с процессором Intel i7 8-го поколения.
  • Все тесты проводились на компьютерах с Ubuntu.

Проблема/Вопрос

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

попробуйте вместо этого использовать locust.io

Lynob 05.10.2022 10:13
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
1
1
141
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий
  1. Глядя на конфигурацию вашего таймера формирования пропускной способности, я вижу, что он настроен на запуск 50 максимальных потоков.
  2. Вы можете достичь 30 запросов в секунду с 50 потоками, только если ваше время отклика будет меньше 1,6 секунды или меньше.
  3. Глядя на время отклика из ваших отчетов, я вижу, что среднее время отклика превышает 2 секунды, и это прекрасно объясняет тот факт, что вы не можете достичь пропускной способности.

Что нужно проверить:

  1. Обязательно следуйте рекомендациям JMeter Best Practices
  2. Убедитесь, что JMeter имеет достаточный запас для работы с точки зрения процессора, оперативной памяти, сети, диска и т. д. Это можно сделать с помощью JMeter PerfMon Plugin
  3. Если вы не можете выполнить требуемую нагрузку с одного экземпляра JMeter — рассмотрите вариант распределенного тестирования
  4. И, наконец, это может быть ваше приложение, которое не может обрабатывать столько запросов в секунду, поэтому стоит проверить его журналы, телеметрию и так далее.

Я просматривал эту статью: blazemeter.com/blog/jmeter-vs-locust вы бы порекомендовали locus вместо JMeter для нашего конкретного случая использования?

abbood 06.10.2022 07:10

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

Dmitri T 06.10.2022 09:11

Другие вопросы по теме