ТимурТорубаров

Здравствуйте.

 

Можно, дорабатывал.

 

Для начала посмотрите на http://jmeter-plugins.org/ , вполне возможно, что что-то из того, что Вам нужно, Вы сможете найти в наборе плагинов. 

Если нет, то пишите класс на java, реализующий логику стрелялки. В качестве примеров можете скачать сорцы на http://jmeter.apache.org/, либо декомпилировать любой из семплеров.

Здравствуйте.

 

Минус первого подхода в том, что Вы указываете схему нагрузки не в RPS, а в Threads (в терминологии JMeter. Далее по тексту - "потоки"), задавая четкую схему использования потоков и задавая максимальную "планку" в RPS Constant Throughput Timer'ом. То есть, в случае, если указанного в Ultimate(Stepping) Thread Group количества потоков Вам будет достаточно для создания бОльшей нагрузки, чем Вы указали в Constant Throughput Timer'е, максимальный RPS вы получите по пределу указанного значения в Timer'е. В случае, если Ваш сервис не отвечает достаточно быстро и указанного количества потоков будет недостаточно для того, чтобы добиться RPS, указанных в Constant Throughput Timer'е, Ваш сервис своими временами ответов будет влиять на создаваемую Вами нагрузку. Чем медленнее он будет отвечать, тем меньше будет нагрузка. Простыми словам указанную схему нагрузки можно описать как "Такое-то количество потоков, изменять так-то, но в RPS не больше, чем в Timer'е". 

 

Во втором подходе Вы заранее создаете пул потоков, часть из которых будет, возможно, простаивать в ожидании, и которые будут использоваться в соответствии со схемой нагрузки в RPS, указанной в Throughput Shaping Timer'е. Независимо от того, как быстро отвечает Ваш сервис, Ваш генератор нагрузки будет придерживаться указанной схемы нагрузки в RPS в Throughput Shaping Timer'е, подключая новые потоки JMeter'а при необходимости.

 

Это два принципиально разных подхода к заданию схемы нагрузки.

Первый - свободными потоками (+в Вашем случае ограниченный в RPS Timer'ом).

Второй - конкретной схемой нагрузки в RPS.

Если Вы можете получить каким-либо запросом id того элемента, который Вы создали, либо этот id как-то возвращается Вам в ответе на POST запрос, то можете записывать его в переменную JMeter при помощи regexp extractor'а, а в дальнейшем использовать её для PUT и DELETE.

Забыл)

 

Как лучше сопоставить проценты с юзерами (number of threads)? 

Извиняюсь, как-то этот вопрос выпал из моего внимания.

 

А зачем Вам это?

В JMeter тред проходит свой сценарий полностью сверху вниз. Что Вы в данной модели нагрузки подразумеваете под "сопоставить проценты с юзерами"? Попробую предположить самый ожидаемый в этом месте сценарий: возможно, у Вас есть необходимость добиться конкретного распределения запросов в соответствии с процентами.

 

В таком случае, нужно немного переделать сценарий. Вам необходимо добавить все Ваши запросы в одну thread group'у, сгруппировав If Controller'ами с условием, которое будет определять вероятность отправки каждой группы запросов, а также добавить Random Variable для генерации случайного числа от 1 до 100.

Случайное число от 1 до 100 с вероятностью 100-N/100 будет больше указанного Вами в if controller'e порога.

Простой сценарий с debug sampler'ами, которые дергаются тред группой с определенность вероятностью, я набросал на коленке и добавил в аттач.

Плюс у Вас под рукой beanshell, там всегда можно написать что-то, что, возможно, будет работать более производительнее, чем пачка if Controller'ов. Они медленны. Следите за CPU на Вашем load-генераторе.

 

P.S. по поводу зацикливания выполнения Thread Group - обратите внимание на чекбокс "loop forever" в настройках Thread Group'ы.

Посмотри на чекбокс

Test Plan -> Run Thread Groups consecutively

Возможно, сервер падает не из-за нагрузки, а из-за конкретной баги. Надо заново подумать, в чем причина.

Потом, из вопроса непонятно, что происходит: Падает веб-приложение или окружение? "Падает" - это появляется ошибка на странице? Перестает работать конкретный функционал? Вообще всё зависает и перестает отвечать? Какие-то коннекты отваливаются?

Для начала, вы уже выяснили, что нагрузка сама по себе не роняет сервер (если, конечно, цифры близки к реальным).
Если воспроизводится достаточно часто, можно попросить разработчиков сделать более подробное логирование и по логам определять критический момент, что же там такое происходит. Потому что может быть банальная утечка ресурсов и переполнение, причем 20 минут - недостаточно, чтобы это привело к падению. Может быть ошибка в логике, которая проявляется при стечении каких-то специфичных условий, и простым манки тестингом ее найти сложно.

Судя по логам сервера, там возникает какая-то ошибка коннекта с базой данных, из-за которой сервер перестает работать и его приходится перезагружать (как это выглядит, я не знаю, мне только поставили задачу убить сервер />/> )

В общем, думаю, что дело действительно не в нагрузке, т.к. с помощью JMeter я подключала пользователей раза в 4 больше, чем есть на самом деле и с более жесткими условиями.

Спасибо большое за ответ!

Проведите тест на длительный промежуток времени.
JMeter у вас виснет скорее всего потому, что заканчивается память. Уберите лишние Listener'ы, выдайте JMeter больше памяти.
Очень желательно хоть как-то мониторить тестируемый сервер, чтобы понимать, что там происходит. В данной ситуации я бы смотрел на учетки памяти и на сокеты.

Под "сломалось" я подразумевал тот момент, когда ваша система перестает отвечать требованиям (начинает выходить за рамки SLA).
К примеру, появляется слишком большой процент медленно выполняющихся запросов. Или появляются сетевые/http ошибки.

Можете уточнить пожалуйста, где смотреть процент медленно выполняющихся запросов, в Aggregate Report, в Error%????
Сетевых ошибок нет, ошибки только "Response code: Non HTTP response code: org.apache.http.conn.HttpHostConnectException
Response message: Non HTTP response message: Connection to http://192.168.2.234:150 refused".
На картинке результаты по 7000 запросов, в Error% стоит 38,7%. Это много? Какй допустимый %?


спасибо большое, да ЦПУ перегружен, слабенький...

На скриншоте, который Вы предоставили, 90% запросов укладываются в 23065мс (это значит, что 90% всех запросов выполнились менее, чем за 23066мс и 10% - дольше).
Количество ошибок в колонке Error - это количество ошибок. Это запросы, в ответ на которые сервер ответил ошибкой вместо правильного ответа. Много ли это или мало - это уже вам решать, но просто само уже наличие ошибок - это не нормально. Какой допустимый процент - вопросы к менеджерам проекта.

Что значит "по 7000 запросов" ? Какую схему нагрузки Вы указывали? Или Вы отправляете запросы в 7000 потоков?
Представьте себе что Вы - владелец супермаркета, Ваш магазин - это вебсервер, покупатели - это клиенты, которые приходят к Вам с запросами, кассиры - это обработчики вашего вебсервера.
Количеством потоков в данном случае будет количество покупателей, которые одновременно подходят на кассы, а производительность - количество покупателей, которые ваши кассы могут через себя пропустить, полностью обслужив. Если поставить ещё касс, то производительность будет увеличиваться, при условии, что у вас хватит денег, чтобы оплатить работу кассиров (хватит ли у вас ресурсов железа, на котором работает ваше ПО). Ошибками будут клиенты, которых не получилось обслужить, или которым надоело ждать в очереди.

Если рассматривать конкретно Ваш случай, то сервер, к которому Вы обращаетесь с запросом, отклоняет запросы на установку соединения, в связи с чем Вы получаете ошибки. Ошибок много. Попробуйте для начала указать шейперу плавно растущую схему нагрузки и ищите момент, когда начинаются ошибки. Используйте графики из Jmeter-plugins.

Откуда берутся значения Производительность и время отклика?

Кстати, крутой отчёт. 147 rps в 0 потоков.

throughput - производительность (запросах в секунду, при малых значениях указывается производительность в запросах в минуту)
max - максимальное время ответа в миллисекундах
average - среднее время ответа в миллисекундах

метрики таймингов не очень полезные в контексте нагрузочного тестирования, лучше используйте процентили (90% line, например. Но эта метрика мало кому подходит по требованиям SLA. Намного более полезны 95%-99% line)

Под "сломалось" я подразумевал тот момент, когда ваша система перестает отвечать требованиям (начинает выходить за рамки SLA).
К примеру, появляется слишком большой процент медленно выполняющихся запросов. Или появляются сетевые/http ошибки.

Вряд ли пользователю сервиса, который Вы тестируете, понравится, если страница загружается 21 секунду и в ответ через 21 секунду приходит "Connection to http://192.168.2.234:150 refused".
Ищите тот момент, на котором появляются ошибки и аномально растёт время ответа.


По поводу шейпера - Вам нужно описать схему нагрузки
100 запросов каждые две секунды - это 50 rps.
Вот пример на пальцах:
Start RPS: 1, End RPS: 50, Duration: 60 sec - нагрузка будет плавно увеличиваться с 1 до 50 в течение 60 секунд
Start RPS: 50, End RPS: 50, Duration: 120sec - нагрузка будет 50 rps в течение 120 секунд.

Откуда берутся значения Производительность и время отклика?

Listener -> Aggregate Report.

Можно по логам Jmeter считать самостоятельно.

1,2) Имеет смысл понять цель нагрузочного тестирования. Скорее всего это поиск точки отказа, а также определение максимального количества запросов в секунду, которое может обработать система. И, скорее всего, определение запаса по сравнению с тем, что есть сейчас в эксплуатации.
Постепенно нагружайте вашу систему до тех пор, пока она не "сломается" и ищите в каком месте это произойдёт. В качестве таймера в вашем тест-плане в этом вам поможет Throughput Shaping Timer из Jmeter-plugins.
Затем сравните полученные значения с тем, что у вас происходит в коммерческой эксплуатации (если она есть) : посчитайте по логам вебсервера какое количество запросов приходит в час пик на тестируемый обработчик.
Не оперируйте понятиями "пользователи". Они разные бывают.

3) Я бы предварительно сгенерировал файл с данными, в котором с нужной мне вероятностью встречались бы нужные мне поисковые запросы, 1 строка - 1 запрос. Далее составил бы тестплан, в котором в качестве параметров построчно считывался бы файл функцией __StringFromFile. Таким образом реализовал бы необходимое соотношение определенных нужных мне поисковых запросов. Здесь вообще большая свобода действий и придумать можно много чего, это лишь один из вариантов. Далее из результатов поискового запроса при помощи Post-processor'а regular expgression extractor я бы регулярным выражением выбирал случайную ссылку на товар и открывал бы страницу с товаром.
Это точно возможно реализовать.

И есть вариант попроще : при наличии логов вебсервера эксплуатации можно взять лог (при необходимости выбрать оттуда нужные запросы) и "скормить" это JMeter. В таком случае не придётся писать какую-либо сценарную логику.

Узнайте у разработчиков на какой url отправляются запросы авторизации. Либо посмотрите в access.log'е вебсервера на какой url отправляет ваша формочка запрос.
Если доступа к серверу\разработчикам нет, то можно tcpdump'ом посниффать траффик, а потом wireshark'ом посмотреть пакеты. При условии, что это не https, конечно же.

Для простых тестов с JMeter'ом не требуется навыков программирования.

Вам нужно провести нагрузочное тестирование веб-сервера, принимающего запросы. Клиент-сайт здесь особой роли не играет.

1. JMeter, Яндекс.Танк или что-либо подобное. У любого инструмента есть свои плюсы и минусы. При желании нагрузить можно даже curl'ом. Пошаговых инструкций в Интернете - море.
2. Ищите в каком месте больше всего загружен ваш веб-сервер или бэкенд, с которым этот вэб-сервер, возможно, работает, во время обработки запросов.