Тестирование производительности LR8.1FP4: cтранное поведение web-прило
#1
Отправлено 03 декабря 2007 - 09:55
Столкнулся с проблемой: проводим тестирование производительности на различном кол-ве юзеров (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. нагрузка создается с одного хоста (удаленного генератора нагрузки) внутри локальной сети
Буду благодарен за советы!
#2
Отправлено 03 декабря 2007 - 10:52
Редактор портала www.it4business.ru
#3
Отправлено 03 декабря 2007 - 12:00
То есть, например, один вечер - 4 часа под нагрузкой одним юзером, в другой вечер - 4 часа под нагрузкой в 10 юзеров и т.д. Для снятия метрик выбирается участок стабильности (когда скачки времен отклика, связаные со стартом юзеров, закончились). Тестировали уже несколько раз, в разное время суток. Относительные результаты одни и те же...
#4
Отправлено 03 декабря 2007 - 12:50
А так бывает вообще? :)сетка (адаптивность к нагрузке, увеличение пропускной способности...)?
А по теме: ищите различия в графиках Transaction Response Time (Percentile) Graph или Average Transaction Response Time Graph [over Time] (в Analysis).
#5
Отправлено 03 декабря 2007 - 13:02
бывает или нет, это как раз и хотел узнать
То, что существуют различные адаптивные алгоритмы маршрутизации, я знаю, а вот дают ли они подобные эффекты - вопрос...
А какие именно искать "различия в графиках"? Можете на примере пояснить?
#6
Отправлено 03 декабря 2007 - 16:11
А какие именно искать "различия в графиках"? Можете на примере пояснить?
Могу чисто теоретически: если статистический момент распределений времени обслуживания различается, то это значит, что и сами распределения
разные, что собственно и является причиной (не корневой) разницы моментов.
Например, первый график для одного пользователя может быть пологим, а для многих - крутым и начинаться ниже, или даже иметь что-то похожее на разрыв вдали от 100pct. Полагаю, кеширование на этом графике так и выглядит, хотя сам внимания на это никогда не обращал.
#7
Отправлено 07 декабря 2007 - 11:53
Что делают Юзеры ?
Как параметризованы их запросы ?
Варианты:
1. Значения параметров запросов уникальны
2. Если есть повторяющиеся значения
Грубо говоря, если есть повторяющиеся запросы, то некоторые приложения за счет кеширования
выполняют их быстрее.
Если у Вас параметры уникальны только в рамках одного пользователя, то будет Ваш случай.
#8
Отправлено 07 декабря 2007 - 13:07
Логин (у всех юзеров различные аккаунты)
Проход по навигации
3 различных поиска (критерии выбираются рандомом из ограниченного набора 5-7 вариантов)
Открытие страницы одного из найденных поисом объектов (выбирается случайным образом из результата поиска)
Логаут
И все юзера крутятся в этом цикле.
Насчет кэширования (Оракла или веб-сервера) я как раз думал, но не видно, чтоб происходил процесс выхода на стационарный режим при нескольких юзерах (т.е. нет участка в начале, когда времена скачут, а потом выравниваются).
Поэтому меня больше интересовал вопрос касательно сетевых "приколов".
#9
Отправлено 07 декабря 2007 - 14:03
Напоминает теханализ. ;) Чтобы не гадать, вот ещё один вариант. Делаете в oracle отчёт statspack за одинаковые промежутки времени в экспериментах с разным количеством пользователей. Смотрите там секцию SQL ordered by Reads. Находите в ней "свои" запросы. Для этих запросов сравниваете Executions, если изменение этого параметра непропорционально увеличению количества пользователей, то значит кеширование в бизнес-логике, а если пропорционально, но различаются Reads per Exec, то это кеш-буфер oracle. Есть и другие варианты, но, думаю, это покрывает процентов 80 случаев.Насчет кэширования (Оракла или веб-сервера) я как раз думал, но не видно, чтоб происходил процесс выхода на стационарный режим при нескольких юзерах (т.е. нет участка в начале, когда времена скачут, а потом выравниваются).
Там наверное есть ещё где-то метрики Time To First Byte, Time To Last Byte, их не пробовали сравнивать? Ну или tcpdump для экстремалов.Поэтому меня больше интересовал вопрос касательно сетевых "приколов".
#10
Отправлено 07 декабря 2007 - 14:09
#11
Отправлено 07 декабря 2007 - 15:03
#12
Отправлено 07 декабря 2007 - 15:25
При первой же возможности проверю предложенные версии и варианты проверок.
Сценарии и их настройки - полностью идентичны...
#13
Отправлено 18 декабря 2007 - 12:02
Доброго времени, коллеги!
Столкнулся с проблемой: проводим тестирование производительности на различном кол-ве юзеров (1,10,25,50...), чтоб получить временные хар-ки в зависимости от нагрузки. Получаем забавные результаты: под нагрузкой одним юзером времена отклика процентов на 20 больше, чем при нагрузке десятью юзерами (например, 2.3сек - 1 юзер и 1.9сек - 10 юзеров). А на 25 юзерах - не хуже, чем при 10, даже на отдельных операциях лучше, чем при 10. Тесты при большем числе юзеров еще не проводили. Боимся, как бы времена не стали отрицательными
Вопросы: кто-нибудь сталкивался с подобным поведением системы? Как трактовать такие результаты?
С чем может быть связано такое поведение: база (кэш), веб-сервер (кэш), сетка (адаптивность к нагрузке, увеличение пропускной способности...)?
А нужно ли вообще так углубляться при трактовке результатов? Судя по параметрам, которые Вы сравниваете (кол-во юзеров и время отклика), вы хотите найти связь между числом юзеров и временем отклика системы. Ваши результаты наглядно показывают, что при нагрузке до 25 юзеров такой связи нет. Все! Влияние этих 25 юзеров мало по сравнению с влиянием других (неизвестных нам) условий, поэтому можно считать, что при 25 юзерах о системе можно не беспокоиться.
P.S. Сам я нагрузкой начал заниматься совсем недавно, поэтому с удовольствием жду критики описанного выше подхода.
А еще у меня вопрос к автору топика.
Вы пишете "даже на отдельных операциях лучше, чем при 10". Как вы выделяете отдельные операции при анализе результатов?
#14
Отправлено 18 декабря 2007 - 12:07
ИМХО, первый пользователь инициализирует какие-то контексты или открывает пул сессий - а остальные уже используют созданные соединения или как-то так. Вопрос не в том, что он один, а в том что он просто первый.
Если я правильно понимаю, то Ваше предположение можно проверить, используя график Connections per Second (кажется как то так). Он показывает количество открываемых коннекшенов во время работы приложения. Если кривая этого графика будет в начале высоко, а со временем убывать, то Ваше предположение верно.
#15
Отправлено 18 декабря 2007 - 13:08
Я имел в виду, что некоторые транзакции (операции) имеют меньшие времена отклика при 25 юзерах, нежели при 10.
#16
Отправлено 18 декабря 2007 - 15:59
Понятно. спасибо.ss12: Как вы выделяете отдельные операции при анализе результатов?
Я имел в виду, что некоторые транзакции (операции) имеют меньшие времена отклика при 25 юзерах, нежели при 10.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных