Перейти к содержимому

Фотография

HELP! Тестирование c Jmeter.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 27

#1 vuchenka

vuchenka

    Постоянный участник

  • Members
  • PipPipPip
  • 174 сообщений
  • ФИО:Ирина
  • Город:Минск

Отправлено 05 декабря 2013 - 08:09

Ребят нужна помощь, загрузили меня нагрузочным тестированием, я в этом практически полный ноль.
Подскажите, как можно выполнить тест и при помощи каких функций.

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

Цель определить при каком количестве пользователей произойдет крах приложения.

1. Есть ли смысл запустить одновременно 500, 1000 и т.д. пользователей? Или это уже похоже на Дос атаки? (запустить только главную страницу).
2. Или запускать с каким-то промежутком? Например каким? И какой подходящий таймер?
3. Как сделать, чтобы одновременно, например 500 пользователей зашли на сайт, и один ввел "шина", выбрал фильтр, потом товар, другой "ролик" выбрал фильтр, потом товар и т.д. Случайный выбор тут как я понимаю не подойдет, т.к. пропустить шаг поиска он не может. Тут надо случайный по группам "шина" и в ней ссылки и по "Ролик" и в ней ссылки. Это возможно реализовать?
  • 0

"Не сломал - значит, не старался!"


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

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

    Активный участник

  • Members
  • PipPip
  • 96 сообщений

Отправлено 05 декабря 2013 - 09:01

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

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

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

#3 vuchenka

vuchenka

    Постоянный участник

  • Members
  • PipPipPip
  • 174 сообщений
  • ФИО:Ирина
  • Город:Минск

Отправлено 05 декабря 2013 - 10:50

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




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

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


1, 2. После 300 одновременных запросов начинают частично появлятся ошибки (
Thread Name: Thread Group 1-3658
Sample Start: 2013-12-05 13:27:03 FET
Load time: 21003
Latency: 0
Size in bytes: 2039
Headers size in bytes: 0
Body size in bytes: 2039
Sample Count: 1
Error Count: 1
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

Response headers:


HTTPSampleResult fields:
ContentType:
DataEncoding: null

О чем это может говорить? И "Сломается" это когда в колонке Status будет все ошибки? или должно сломатся приложение и т.п).

А как выставить значения в Throughput Shaping Timer. Например, надо выставить 100 запросов каждые 2 секунды.

3. Ой, все так тяжело, мне пока не понять. По поводу логов веб-сервера. программисты сказали, что там у нас хранятся только ошибки.
  • 0

"Не сломал - значит, не старался!"


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

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

    Активный участник

  • Members
  • PipPip
  • 96 сообщений

Отправлено 05 декабря 2013 - 13:27

Под "сломалось" я подразумевал тот момент, когда ваша система перестает отвечать требованиям (начинает выходить за рамки 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 секунд.
  • 1

#5 vuchenka

vuchenka

    Постоянный участник

  • Members
  • PipPipPip
  • 174 сообщений
  • ФИО:Ирина
  • Город:Минск

Отправлено 05 декабря 2013 - 14:26

Под "сломалось" я подразумевал тот момент, когда ваша система перестает отвечать требованиям (начинает выходить за рамки 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 секунд.



спасибо большое, и еще один вопросик, при 7000 одновременных запросов тестирование идет более ли менее быстро, а вот уже более 7000 не идет, виснет комп. Это о чем может говорить? Может jmeter более 7000 не может обработать?) комп мощный, 6 гб оперативы, процессор: Intel® Core™ i3 CPU 550 @ 3.20 GHz 3.19 GHZ
  • 0

"Не сломал - значит, не старался!"


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

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

    Активный участник

  • Members
  • PipPip
  • 96 сообщений

Отправлено 05 декабря 2013 - 14:36

У Вас бюджетный офисный ПК, судя по процессору. Мониторьте загрузку Вашего ПК, с которого создаете нагрузку. Скорее всего, заканчивается цпу.
  • 0

#7 UnSkill

UnSkill

    Новый участник

  • Members
  • Pip
  • 8 сообщений

Отправлено 05 декабря 2013 - 15:00

Да уж..мощный комп)
  • 0

#8 vuchenka

vuchenka

    Постоянный участник

  • Members
  • PipPipPip
  • 174 сообщений
  • ФИО:Ирина
  • Город:Минск

Отправлено 06 декабря 2013 - 06:29

...
  • 0

"Не сломал - значит, не старался!"


#9 vuchenka

vuchenka

    Постоянный участник

  • Members
  • PipPipPip
  • 174 сообщений
  • ФИО:Ирина
  • Город:Минск

Отправлено 06 декабря 2013 - 06:30

Под "сломалось" я подразумевал тот момент, когда ваша система перестает отвечать требованиям (начинает выходить за рамки 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%. Это много? Какй допустимый %?


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

Прикрепленные файлы

  • Прикрепленный файл  .3.png   13,86К   73 Количество загрузок:

  • 0

"Не сломал - значит, не старался!"


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

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

    Активный участник

  • Members
  • PipPip
  • 96 сообщений

Отправлено 10 декабря 2013 - 11:54


Под "сломалось" я подразумевал тот момент, когда ваша система перестает отвечать требованиям (начинает выходить за рамки 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.
  • 1

#11 puchock

puchock

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Пучок

Отправлено 13 декабря 2013 - 18:08

Или Вы отправляете запросы в 7000 потоков?

ТимурТорубаров, может хватит с потоком вопросов и странных ассоциаций? Ни к какому пониманию новичком решения задачи они не ведут - это очевидно! Не буду углубляться по поводу, какую реакцию вы у меня вызываете (сомневаюсь, что вы сами глубоко понимаете и практикуете в load). Спасибо.

Перехожу к сути, обращаюсь к тому, кто знает и может понятно объяснить vuchenka (присоединяюсь к ней по данной теме, упрощая её задачу): как на JMeter реализовать два get-запроса (фильтрация, выбор товара) в поток с интенсивностью 500 (а можно замахнуться и на 1000) запросов в секунду на серверной стороне, (где, допустим, нет соответствующей dos-защиты)?
1. пожалуйста, проиллюстрируйте решение (скриншоты с TestPlan и параметрами его компонентов, а лучше jmx-файл).
2. как при этом в сценарии должно быть учтено время отклика (всё, что входит во временные затраты от submit'а до окончания прихода respons'а)?
3. можно ли 500, 1000 rps (каков предел?) добиться с машины, конфигурацию которой привела vuchenka (в чём специфика связи нагрузочного сценария с объёмом озу, производительностью процессора...)?
4. какие рекомендуются параметры запуска jmeter-процесса?
5. имеется ли специфика/ограничения, связанные с инфраструктурой, в которой выполняется нагрузка?
...что ещё не учёл?...
Буду очень благодарен за профессиональный ответ(ы)!
  • 0

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

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

    Активный участник

  • Members
  • PipPip
  • 96 сообщений

Отправлено 14 декабря 2013 - 14:06

Вопросы в данном случае необходимы, так как vuchenka не может внятно объяснить то, что ей необходимо от тестов, к тому же путается в терминологии и задает странные вопросы.
Например, тремя сообщениями выше vuchenka написала следующее:

"На картинке результаты по 7000 запросов, в Error% стоит 38,7%. Это много? Какй допустимый %?"

И любой человек, который посмотрит на картинку в аттаче задастся совершенно справедлиным вопросом - какие еще "по 7000 запросов" и что в данном случае имелось в виду? Если имелось в виду общее количество запросов, то в Aggregate Report'е видно, что за весь тест от начала до конца было отправлено всего 5000 реквестов, причем неизвестно с какой интенсивностью. Из предоставленной информации нельзя сделать абсолютно никаких выводов. К тому же, нагрузочные тесты имеют смысл на значимом для работы Вашего сервера промежутке времени.
Ассоциации я привел с целью объяснить важные элементы механизма работы JMeter, а также работы вебсерверов, которые нагрузочному тестировщику важно знать и хотя бы в каком-то виде представлять, а из общения с vuchenka складывается впечатление, что она не понимает принципиального отличия количества потоков от производительности. Это совершенно разные вещи. И лучше всего для объяснения этого подходят простейшие элементы из теории массового обслуживания и это новички должны осознавать в первую очередь, чтобы не быть мартышками, которые просто нажимают на кнопку.

Ко всему прочему, у всех инструментов есть свои плюсы и минусы.
Инструмент JMeter, при помощи которого Вы создаете нагрузку, создает её, используя синхронный пул потоков. Это значит, что у самого JMeter у каждой тред группы есть пул потоков, который он использует для создания нагрузки. Количество потоков вы указываете в настройках Thread Group'ы в графе "Number of threads". Каждый поток тред группы выполняет сценарий (описанный в данной Thread Group'е) сверху вниз, независимо от других потоков.
И в том случае, если 1 поток тред группы успевает выполнить сценарий в течение 1 мс 1000 раз подряд (допустим, что Ваш сервер отвечает достаточно быстро), то уже 1 потока будет достаточно для создания нагрузки в 1000rps (1мс х 1000 = 1сек). И всё это будет очень слабо похоже на реальную нагрузку, которую создают реальные пользователи, потому что инструмент, при помощи которого Вы создаете нагрузку, будет отправлять в таком случае запросы последовательно (выполнился один - отправлен следующий), поэтому вебсервер, к которому Вы обращаетесь, будет получать и обрабатывать запросы также последовательно. Это справедливо при условии, что Вы напрямую обращаетесь к вебсерверу, без асинхронных очередей и обработчиков.
Если же Ваш сервер будет отвечать долго, к примеру, 20 секунд, то при помощи 1 потока Вы добьетесь только 3 запросов в минуту, т.к. поток будет "висеть", ожидая выполнения запроса. Теперь представьте себе ситуацию, когда одни и те же запросы могут выполняться произвольное количество времени, а часть запросов может "подвисать" (что в реальности и происходит чаще всего), в таком случае реальная схема Вашей нагрузки будет представлять из себя "пилу".

В связи с этим для JMeter был написан плагин, позволяющий минимизировать минусы подобного механизма работы. Называется плагин Throughput Shaping Timer. Используя его, Вы сможете задавать необходимую Вам схему нагрузки, которой Ваш JMeter будет придерживаться. Суть работы плагина проста - пока JMeter не добьется указанной схемы нагрузки в Throughput Shaping Timer, он будет подключать всё новые и новые потоки (до тех пор, пока потоки не закончатся, либо до тех пор, пока ему не удастся добиться RPS, указанных в схеме нагрузки плагина для текущего момента теста). Количество потоков при этом необходимо будет задать по формуле "RPS * <max response time> / 1000". К примеру, если Ваш вебсервис отвечает 2.5 секунды, а Вы хотите добиться 1230 rps, то количество потоков, которые нужно выставить тред группе 1230 * 2500 / 1000 = 3075. Это самый эффективный способ создания нагрузки при помощи JMeter в том случае, если Вы хотите более-менее строго придерживаться какого-то конкретного значения RPS в тестах.

Поэтому, ответить на Ваш вопрос

"как на JMeter реализовать два get-запроса (фильтрация, выбор товара) в поток с интенсивностью 500 (а можно замахнуться и на 1000) запросов в секунду на серверной стороне"

можно, но любой человек, разбирающийся в вопросе тестирования производительности уточнит и задаст дополнительный вопрос : для чего Вам делать запросы с интенсивностью 500(1000) запросов в секунду в поток? После таких тестов у Вас получатся результаты, абсолютно не соответствующие действительности и не имеющие никакого смысла, не говоря уже о практическом применении.



1. Добавил пример сценария в аттач (Заархивировал, т.к. форум не дает аплоадить файлы с расширением .jmx). Допустим, я знаю, что мой сервер отвечает максимум в течение 100 мс. В связи с этим я выставил количество потоков в 100. При этом в схеме нагрузки в течение 60 секунд будет плавно расти нагрузка с 1 до 500 rps, далее зафиксируется на 3 минуты на 500 rps, далее поднимется в течение минуты с 500 до 1000 и в течение минуты опустится с 1000 до 1.
Хост в HTTP Sampler'ах указал специально несуществующий, замените его на свой (тестировал на lamoda.ru , но осмысленно убрал, чтобы Вы по-неопытности нагрузочно не тестировали и без того не производительный фронт ламоды :)).

Сценарий состоит из:
  • трёх HTTP Sampler'ов - это элементы создания HTTP запросов
    • заход на главную страницу, в данном случае testtesttesttesttest.ru
    • поисковый запрос "test", из которого Post Processor Regular Extractor'ом выбирается регулярным выражением "<a class="products-list-item" href="(/p/\w+/\D+)\?.*" параметр для последующего запроса - ссылка
    • заход на карточку товара
  • Aggregate Report'а - элемент агрегатов теста
  • View Results Tree - элемент позволяет смотреть какие конкретно запросы были отправлены, какие получены ответы и подобную информацию
  • jp@gc Transactions per second - график, по оси абсцисс время от начала теста, по оси ординат количество запросов в секунду.
  • jp@gc Throughput Shaping Timer - элемент схемы нагрузки, подробнее о том, как им пользоваться, можете почитать тут : http://jmeter-plugin...utShapingTimer/

2. В сценарии время отклика Вы можете учитывать Duration Assertion'ом. Просто добавляете подобный Assertion к HTTP Sampler'у и указывете время в миллисекундах, по истечению которого запрос нужно считать ошибкой. Однако, в такое случае сложно будет находить реальные ошибки. Поэтому, куда как проще без Asserion'а просто смотреть "глазами" в Aggregate Report'е 90% line времени выполнения запросов.
3,4. Непосредственно для создания нагрузки необходим в основном CPU. Каков предел для Вашей машинки в цифрах Вам никто не скажет. Можете самостоятельно отслеживать момент, когда CPU на лоадгенераторе заканчивается и условно считать это максимумом. Если планируются длительные тесты с графиками и Вам необходимо хранить много данных в Listener'ах, то выставьте размер HEAP больше. По-умолчанию там должно быть 512Mb. Всё остальное должно работать из коробки и править ничего не нужно.
5. Что Вы подразумеваете под инфраструктурой, в которой выполняется нагрузка? Очень желательно, чтобы Ваш лоад генератор и вебсервер, который Вы нагружаете, были на разном физическом железе и подключены в один коммутатор, чтобы минимизировать коллизии сети. Если ответы Вашего вебсервера большие, то необходимо удостовериться, что узким местом в тестах не является сеть.

Обратите особое внимание на HTTP Keep-alive. И телеметрию: мониторинг серверов (как тестируемых, так и лоад-генераторов) обязательно должен присутствовать в каком-либо виде.

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

Прикрепленные файлы


  • 0

#13 puchock

puchock

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Пучок

Отправлено 17 декабря 2013 - 20:34

из общения с vuchenka складывается впечатление, что она не понимает принципиального отличия количества потоков от производительности. Это совершенно разные вещи. И лучше всего для объяснения этого подходят простейшие элементы из теории массового обслуживания и это новички должны осознавать в первую очередь, чтобы не быть мартышками, которые просто нажимают на кнопку

1. При чём здесь теория массового обслуживания? Вы-то в ней разбираетесь?
1.1 Похоже, вы источники потоков требований (потоки jmeter-процесса) путаете с приёмниками. Мы же ведём речь не о выборе структуры системы обслуживания запросов, а о формировании генератора требуемой интенсивности потока требований, направленных в "чёрный ящик".
1.2 Очевидно у вас нет понимания и того, что потоки запросов jmeter - это не аналоги независимых потоков/очередей к приборам обслуживания (из теории МО), а конкурентные кореллированные явления в рамках одного процесса.

2. Ваш сценарий даже не могу серьёзно воспринимать. Что вы вообще думаете, рекомендуя в потенциально жёстком нагрузочном процессе, где требуется свести к минимуму ресурсоёмкость/времязатраты, использовать постпроцессоры c регулярными выражениями?

3. С одной стороны очевидна синхронность выполнении jmeter-сценария и что, чем больше становится нагрузка на сервер, тем дольше будет время отклика, и, наступает момент (например, достигли 500 rps), когда с jmeter'а становится невозможно увеличить интенсивность запросов. С другой стороны - вы утверждаете, что Throughput Shaping Timer начнёт совершать чудо, выстреливая столько дополнительных потоков, сколько надо для желаемого более высокого значения rps. Но вы понимаете, что чуда не произойдёт? Кратковременное увеличение числа потоков приведёт к outOfMemory на фоне включения тормозов с переключением контекстов в многопоточном процессе!

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

Спасибо, ТимурТорубаров, ещё раз за участие, но, к сожалению, у меня понимания не прибавилось относительно способов организации, методики как несколькими get-запросами корректно организовать/сгенерировать нагрузку, максимальную, которую можно выжать из машины, конфигурацию которой привела vuchenka, т.е. реализовать входящий поток большой интенсивности (обойти проблему, описанную в пп.3 выше) с jmeter, когда сокет ещё может ещё принимать запросы и backend обрабатывать их очередь на фоне замораживающегося исходящего потока ответов.

Люди с прямыми руками и светлой головой, можно или нет jmeter'ом, который позиционирован как серьёзная нагрузочная тулза, пользоваться (небезбашенно) как кувалдой? пожалуйста, дайте дельный совет! или он всего лишь лёгкое пёрышко, изображённое на логотипе?
  • 0

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

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

    Активный участник

  • Members
  • PipPip
  • 96 сообщений

Отправлено 18 декабря 2013 - 10:22

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

Люди с прямыми руками и светлой головой, можно или нет jmeter'ом, который позиционирован как серьёзная нагрузочная тулза, пользоваться (небезбашенно) как кувалдой? пожалуйста, дайте дельный совет! или он всего лишь лёгкое пёрышко, изображённое на логотипе?

JMeter - это серьезный нагрузочный инструмент. Механизм генерации нагрузки и как инструментом пользоваться "небезбашенно" я попытался Вам объяснить в предыдущем своем сообщении. По-моему, я написал доступно про потоки JMeter и объяснять повторно смысла не вижу. Не понимаю, к чему Вы обращаете мое внимание на "конкурентные коррелированные явления в рамках одного процесса" - это совершенно не имеет никакого отношения к делу и к сути того, о чём я писал. Обратите особое внимание на то, что при использовании инструмента, который использует для генерации запросов синхронный пул потоков, ваш тестируемый "черный ящик" может (и будет!) влиять на генерируемую Вами нагрузку. И нет никакого смысла разводить в данном месте демагогию : про шейпер я говорил именно в этом контексте. Он нужен не для чудес, а для достижения необходимой точности в тестах. О достаточной мощности железа Вы должны позаботиться заранее, чтобы избежать oom/csw.

По всем остальным пунктам я могу посоветовать Вам:
  • Найти нормальную железку под лоад-генератор, а не бюджетный ПК на core i3, чтобы вся затея с тестированием выглядела "серьезно", как Вы и хотите. Для генерации серьезной и стабильной нагрузки необходим серьезный лоад-генератор. При наличии нескольких подобных железок JMeter можно горизонтально масштабировать (из коробки).
  • Определиться с требованиями. То Вам необходима сценарная логика с поиском и выборкой, то Вы отвергаете варианты её создания, т.к. "требуется свести к минимуму ресурсоёмкость/времязатраты". Сейчас Ваше пожелание выглядит как "у меня есть деревянный ящик из под пива и 4 колеса, как мне сделать из этого феррари?".

Я понимаю, что у Вас есть задача и есть конкретное железо, при помощи которого надо эту задачу решить.
Но на самом деле у Вас две проблемы, если закрыть глаза на неопределенность в требованиях:
  • слабое железо
  • необходимость проведения качественного тестирования с высоким RPS
Одна из них противоречит другой. Как быть решать Вам.
  • 0

#15 puchock

puchock

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Пучок

Отправлено 18 декабря 2013 - 20:13

Я понимаю, что у Вас есть задача и есть конкретное железо, при помощи которого надо эту задачу решить.
Но на самом деле у Вас две проблемы, если закрыть глаза на неопределенность в требованиях:

  • слабое железо
  • необходимость проведения качественного тестирования с высоким RPS
Одна из них противоречит другой. Как быть решать Вам.

1. Где вы видите противоречие в стремлении понимать - как из того, что есть извлекать максимум, на что оно способно?
2. Поймите наконец - у меня ничего описанного вами нет - ни подобного железа, ни проблем с заданием vuchenka, кроме желания опосредованно ей помочь. Cравните, как вы с ней свысока канителили и совсем по другому заговорили со мной! Оставим это на вашей совести, - главное, чтобы она смогла разобраться с задачей и подходами к её решению.
3. При чём здесь Яндекс.Танк? ваш юмор (вы здесь ещё писали и про Феррари) не останется без внимания. Если оно вам нужно, то вы им и пользуйтесь, а vuchenka спрашивала на форуме про JMeter (ещё Apache - вертолёт, предназначенный в первую очередь для эффективной борьбы с танками).
4. Заметим, на этот раз вы не предложили никакой концепции, кроме - найти мощное железо и горизонтально масштабировать, тогда jmeter будет серьёзным тулом. Знаете ли вы, ТимурТорубаров, что "и с малой силой, сударь, при уменье можно делать великие дела"?
5. Спасибо вам ещё раз за участие, но я верю, что и на машине vuchenka можно выжать приличную нагрузку, только для этого нужно знать "секреты" jmeter - эта информация меня заинтересовала... но тех, кому я не скажу "спасибо, кэп!!!" это почему-то не цепляет...
  • 0

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

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

    Активный участник

  • Members
  • PipPip
  • 96 сообщений

Отправлено 19 декабря 2013 - 09:13

Да понял я.
Вы видите только то, что Вам удобно и хочется видеть.
И зарегистрировались на форуме только для того, чтобы довольно неумело и безрезультатно меня троллить.
В связи с этим дальнейшую дискуссию с Вами считаю нецелесообразной.
  • 0

#17 lfduch

lfduch

    Новый участник

  • Members
  • Pip
  • 3 сообщений

Отправлено 19 декабря 2013 - 09:24

1. Где вы видите противоречие в стремлении понимать - как из того, что есть извлекать максимум, на что оно способно?
2. Поймите наконец - у меня ничего описанного вами нет - ни подобного железа, ни проблем с заданием vuchenka, кроме желания опосредованно ей помочь. Cравните, как вы с ней свысока канителили и совсем по другому заговорили со мной! Оставим это на вашей совести, - главное, чтобы она смогла разобраться с задачей и подходами к её решению.
3. При чём здесь Яндекс.Танк? ваш юмор (вы здесь ещё писали и про Феррари) не останется без внимания. Если оно вам нужно, то вы им и пользуйтесь, а vuchenka спрашивала на форуме про JMeter (ещё Apache - вертолёт, предназначенный в первую очередь для эффективной борьбы с танками).
4. Заметим, на этот раз вы не предложили никакой концепции, кроме - найти мощное железо и горизонтально масштабировать, тогда jmeter будет серьёзным тулом. Знаете ли вы, ТимурТорубаров, что "и с малой силой, сударь, при уменье можно делать великие дела"?
5. Спасибо вам ещё раз за участие, но я верю, что и на машине vuchenka можно выжать приличную нагрузку, только для этого нужно знать "секреты" jmeter - эта информация меня заинтересовала... но тех, кому я не скажу "спасибо, кэп!!!" это почему-то не цепляет...


г-н puchock зачем вы все это тут пишите? это никому не интересно! если у вас есть буквы по теме и вы действительно хотите поделиться своими наработками или знаниями тогда пишите конкретику а свои чувства к участникам форума и философские размышления пишите пожалуйста в личку!
  • 0

#18 puchock

puchock

    Новый участник

  • Members
  • Pip
  • 15 сообщений
  • ФИО:Пучок

Отправлено 19 декабря 2013 - 23:10

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

lfduch, почему вы утверждаете за всех?
во-первых, вы у постера спросили: прибавилось ли у него понимания, не пропал ли интерес к теме нагрузочного тестирования, прояснились ли приёмы использования jmeter, (лично я частично привёл свои знания в порядок).
во-вторых, пожалуйста, не указывайте здесь ни мне ни кому бы то ни было - что и куда участники форума должны или не должны писать. Если вы из группы поддержки Тимура и вам самому нечего добавить по существу вопроса, то, будьте добры, сами же и воспользуйтесь своим советом.
Жаль, если профессиональные мнения/рекомендации на данный вопрос нагрузочного тестирования закончились.
  • 0

#19 ligreen

ligreen

    Новый участник

  • Members
  • Pip
  • 52 сообщений

Отправлено 20 декабря 2013 - 11:02

Интересно как у Алеси продвинулись дела по задачке....
  • 0

#20 APC

APC

    Опытный участник

  • Members
  • PipPipPipPip
  • 293 сообщений
  • ФИО:Похилько Андрей Федорович
  • Город:Москва


Отправлено 20 декабря 2013 - 13:39

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

lfduch, почему вы утверждаете за всех?
во-первых, вы у постера спросили: прибавилось ли у него понимания, не пропал ли интерес к теме нагрузочного тестирования, прояснились ли приёмы использования jmeter, (лично я частично привёл свои знания в порядок).
во-вторых, пожалуйста, не указывайте здесь ни мне ни кому бы то ни было - что и куда участники форума должны или не должны писать. Если вы из группы поддержки Тимура и вам самому нечего добавить по существу вопроса, то, будьте добры, сами же и воспользуйтесь своим советом.
Жаль, если профессиональные мнения/рекомендации на данный вопрос нагрузочного тестирования закончились.


+1 к lfduch. Товарищ puchock переходит на личности и не приносит пользы делу.

А Тимур - нагрузочный тестировщик в Яндексе. И он старается не просто ответить на вопрос кратко, а объяснить закономерности в нагрузочном тестировании.
  • 1


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных