Сообщений в теме: 15

[Сэм]

Доброго времени, коллеги!

Столкнулся с проблемой: проводим тестирование производительности на различном кол-ве юзеров (1,10,25,50...), чтоб получить временные хар-ки в зависимости от нагрузки. Получаем забавные результаты: под нагрузкой одним юзером времена отклика процентов на 20 больше, чем при нагрузке десятью юзерами (например, 2.3сек - 1 юзер и 1.9сек - 10 юзеров). А на 25 юзерах - не хуже, чем при 10, даже на отдельных операциях лучше, чем при 10. Тесты при большем числе юзеров еще не проводили. Боимся, как бы времена не стали отрицательными

Вопросы: кто-нибудь сталкивался с подобным поведением системы? Как трактовать такие результаты?
С чем может быть связано такое поведение: база (кэш), веб-сервер (кэш), сетка (адаптивность к нагрузке, увеличение пропускной способности...)?

Условия тестирования:
1. Веб-приложение (WebLogic)
2. Oracle
3. локальная сетка заказчика (информация о ее структуре и настройках недоступна)
4. в среднем все времена отклика лежат в интервале от 0.5сек до 6сек.
5. тул - LR8.1 FP4
5. нагрузка создается с одного хоста (удаленного генератора нагрузки) внутри локальной сети

Буду благодарен за советы!

[Case]

ИМХО, первый пользователь инициализирует какие-то контексты или открывает пул сессий - а остальные уже используют созданные соединения или как-то так. Вопрос не в том, что он один, а в том что он просто первый.

[Сэм]

Боюсь, что как раз тут дело в кол-ве юзеров. Эти тесты мы проводим отдельно.
То есть, например, один вечер - 4 часа под нагрузкой одним юзером, в другой вечер - 4 часа под нагрузкой в 10 юзеров и т.д. Для снятия метрик выбирается участок стабильности (когда скачки времен отклика, связаные со стартом юзеров, закончились). Тестировали уже несколько раз, в разное время суток. Относительные результаты одни и те же...

[a66at]

сетка (адаптивность к нагрузке, увеличение пропускной способности...)?

А так бывает вообще? :)

А по теме: ищите различия в графиках Transaction Response Time (Percentile) Graph или Average Transaction Response Time Graph [over Time] (в Analysis).

[Сэм]

2 a66at:
бывает или нет, это как раз и хотел узнать
То, что существуют различные адаптивные алгоритмы маршрутизации, я знаю, а вот дают ли они подобные эффекты - вопрос...

А какие именно искать "различия в графиках"? Можете на примере пояснить?

[a66at]

А какие именно искать "различия в графиках"? Можете на примере пояснить?

Могу чисто теоретически: если статистический момент распределений времени обслуживания различается, то это значит, что и сами распределения
разные, что собственно и является причиной (не корневой) разницы моментов.

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

[SD_KOROLEV]

Разрешите слово молвить !

Что делают Юзеры ?

Как параметризованы их запросы ?

Варианты:
1. Значения параметров запросов уникальны
2. Если есть повторяющиеся значения

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

[Сэм]

Юзера не делают ничего хитрого:
Логин (у всех юзеров различные аккаунты)
Проход по навигации
3 различных поиска (критерии выбираются рандомом из ограниченного набора 5-7 вариантов)
Открытие страницы одного из найденных поисом объектов (выбирается случайным образом из результата поиска)
Логаут

И все юзера крутятся в этом цикле.

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

Поэтому меня больше интересовал вопрос касательно сетевых "приколов".

[a66at]

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

Напоминает теханализ. ;) Чтобы не гадать, вот ещё один вариант. Делаете в oracle отчёт statspack за одинаковые промежутки времени в экспериментах с разным количеством пользователей. Смотрите там секцию SQL ordered by Reads. Находите в ней "свои" запросы. Для этих запросов сравниваете Executions, если изменение этого параметра непропорционально увеличению количества пользователей, то значит кеширование в бизнес-логике, а если пропорционально, но различаются Reads per Exec, то это кеш-буфер oracle. Есть и другие варианты, но, думаю, это покрывает процентов 80 случаев.

Поэтому меня больше интересовал вопрос касательно сетевых "приколов".

Там наверное есть ещё где-то метрики Time To First Byte, Time To Last Byte, их не пробовали сравнивать? Ну или tcpdump для экстремалов.

[a66at]

P.S. У вас в обоих случаях один и тот же сценарий используется? В смысле включенность/выключеннность think time одинаковая?

[Rifle]

А существует возможность провести проверку с двух компьютеров, т-е генерировать часть запросов с одного и в это же время с друго компьютера, интересно какова будет тенденция?

[Сэм]

Спасибо за ответы!
При первой же возможности проверю предложенные версии и варианты проверок.
Сценарии и их настройки - полностью идентичны...

[ss12]

Доброго времени, коллеги!

Столкнулся с проблемой: проводим тестирование производительности на различном кол-ве юзеров (1,10,25,50...), чтоб получить временные хар-ки в зависимости от нагрузки. Получаем забавные результаты: под нагрузкой одним юзером времена отклика процентов на 20 больше, чем при нагрузке десятью юзерами (например, 2.3сек - 1 юзер и 1.9сек - 10 юзеров). А на 25 юзерах - не хуже, чем при 10, даже на отдельных операциях лучше, чем при 10. Тесты при большем числе юзеров еще не проводили. Боимся, как бы времена не стали отрицательными

Вопросы: кто-нибудь сталкивался с подобным поведением системы? Как трактовать такие результаты?
С чем может быть связано такое поведение: база (кэш), веб-сервер (кэш), сетка (адаптивность к нагрузке, увеличение пропускной способности...)?

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

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

А еще у меня вопрос к автору топика.
Вы пишете "даже на отдельных операциях лучше, чем при 10". Как вы выделяете отдельные операции при анализе результатов?

[ss12]

ИМХО, первый пользователь инициализирует какие-то контексты или открывает пул сессий - а остальные уже используют созданные соединения или как-то так. Вопрос не в том, что он один, а в том что он просто первый.

Если я правильно понимаю, то Ваше предположение можно проверить, используя график Connections per Second (кажется как то так). Он показывает количество открываемых коннекшенов во время работы приложения. Если кривая этого графика будет в начале высоко, а со временем убывать, то Ваше предположение верно.

[Сэм]

ss12: Как вы выделяете отдельные операции при анализе результатов?
Я имел в виду, что некоторые транзакции (операции) имеют меньшие времена отклика при 25 юзерах, нежели при 10.

[ss12]

ss12: Как вы выделяете отдельные операции при анализе результатов?
Я имел в виду, что некоторые транзакции (операции) имеют меньшие времена отклика при 25 юзерах, нежели при 10.

Понятно. спасибо.