Разработка модели нагрузки
Поскольку в профиле нагрузки как правило присутствует несколько операций - это означает, что у нас будет несколько групп пользователей. Желательно моделировать каждую операцию отдельной группой виртуальных пользователей (хотя в жизни часто бывает наоборот, один бизнес пользователь может отвечать за выполнение нескольких операций). Тем не менее, если назначить одному виртуальному пользователю выполнение одной операции то так легче выдержать определенную интенсивность (и соответственно производительность) для этой операции в тесте чем в случае, когда виртуальному пользователю назначается последовательная цепочка операций. Зная интенсивность выполнения операции нужно определить количество виртуальных пользователей в группе, выполняющих эту операцию. Идеальный случай когда работа с приложением аналогична работе заводского конвейра и есть точные оценки сколько операций в день делает один пользователь. Чаще всего бывает не так и известно только общее количество операций выполняемое в течение дня. Так же может оказаться, что интенсивность выполнения операции каждым пользователем очень низкая, например, один пользователь выполняет операцию раз в день или раз в два дня.
Моделирование работы с пересчетом интенсивностей в этом случае можно проиллюстрировать следующим примером
ПРИМЕР: (для одной операции)
Количество операций = 200 за 4 часа
Количество бизнес пользователей = 20
---------------------------------------
1. Определяем количество операций для каждого пользователя
200/20 = 10
2. В час каждый пользователь выполняет 2.5 операции
10/4 = 2.5
3. Определяем период повторения операции (интенсивность) для каждого пользователя
60/2.5 = 24 минуты
4. Чтобы уменьшить время теста до часа, и при этом получить хоть какую то статистику по выполнению операций, а так же улучшить "перемешивание" операций во время теста, можно увеличить интенсивность в 4 раза, при этом уменьшив количество пользователей так же в 4 раза.
24/4 = 6 мин. = 360 секунд
Таким образом, 5 виртуальных пользователей, выполняя операцию с периодом 6 минут, обеспечат за 4 часа заданную производительность равную 200 операциям.
Что дает такой пересчет :
Во-первых, есть возможность снизить время теста, не теряя статистики выполнения операций, а следовательно и достоверности результатов теста. Во-вторых, можно снизить количество моделируемых пользователей там где их число уходит за несколько тысяч и таким образом понизить требования к количеству ресурсов нагружающих компьютеров (1VU может требовать до 10Мб оперативной памятинагружающего компьютера ), а в некоторых случаях и выполнить условия лицензионного соглашения (стоимость лицензии для тестового инструментария зависит от количества виртуальных пользователей)
Какие есть ограничения :
Для некоторых приложений, может быть критично количество одновременно открываемых соединений между клиентом и сервером. Встречались ситуации когда запросы к базе данных начинали работать значительно медленнее если при работе с приложением увеличивается количество именно разных пользователей (разные логины) а не интенсивность запросов. И наконец, увеличение интенсивности выполнения операций, не должно приводить к ситуации когда период повторения становится меньше чем время выполнения самой операции.
В любом случае, несмотря на некоторые ограничения, подобный расчет может допускать варьирование количеством виртуальных пользователей и интенсивностью выполнения ими операций. При этом производительность и соответственно нагрузка не должна изменяться и отличаться от заданной. Итак, нагрузочная точка включает в себя расчеты виртуальных пользователей и интенсивностей по всем операциям профиля нагрузки.
Дополняем терминологию :
8. Нагрузочной точкой называется расчитанное (либо заданное Заказчиком) количество виртуальных пользователей в группах, выполняющих операции с определенными интенсивностями.
Комментарии: 10:
Андрей, вот у меня вопрос из жизни.
Зачастую заказчики сами не знают, что им нужно и что у них уже есть.
Пример их задания:
- Вот вам наша система, мы хотим проверить, что она выдерживает 100 пользователей.
Все остальное они не знают и часто отвечают фразой типа: вы профи вы должны знать какая должна быть интенсивность и время теста.
Вот я и спрашиваю, как быть в этой ситуации, на основании каких данных проводить расчет нагрузки и построение модели?
Заранее спасибо
Автор: А.Б., В 10 февраля 2009 г. в 06:53
Леша, привет! Могу тебе как раз из жизни консультанта-тестировщика сказать, что заказчики вникают в то, что они хотят получить от нагрузочного тестирования:)(особенно на аутсорсинге, когда за это удовольствие надо платить!). И понимание, что 100 пользователей могут создавать совершенно разные виды нагрузки у них как правило есть. И то, что без помощи их разработчиков, админов, бизнес пользователей (именно для того, чтобы понять интенсивности и специфику нагрузки) не обойтись тоже как правило удается убедить.
Со своей стороны можно "выудить" тяжелые запросы изучая статистику работы СУБД. Для Оракла 9 я обычно прошу собрать статс-паки. Для SQL Server 2000-2005 есть свои приемы мониторинга "тяжелых" операций (наверно в ближайших статьях опишу)...Но все равно полученные списки желательно обсудить со специалистами заказчика, чтобы в результате определить круг моделируемых операций. Интесивности выполнения с какой то точностью тоже можно определить по логам различных серверов но... повторяю, что сходу получить уровень понимания работы тестируемого ПО аналогичный тому, кто ее использует или разрабатывает довольно трудно. Так что надо убеждать заказчика активно участвовать в работе и помогать.
Автор: Андрей, В 10 февраля 2009 г. в 11:19
Андрей, спасибо.
Пример, который написал - пример из жизни.
Автор: А.Б., В 11 февраля 2009 г. в 02:30
Леша, если все-таки ситуация такова, что у заказчика на момент начала проекта нет готовых ответов на наши вопросы по работе тестируемого Приложения, то можно попробовать следующее:
1.Приложение находится в эксплуатации и его тестируют потому что ожидается новая версия, расширение бизнеса или подбор новой конфигурации оборудования:
Если приложение основано на СУБД и размеры базы данных значительны то, скорее всего, "проблемы" с производительностью будут здесь. В зависимости от типа СУБД необходимо получить статистику по "тяжелым" запросам. И у Оракла и у MS SQL такая возможность есть, и думаю, что скоро выложу методику по исследованию MS SQL Server-а в блоге. Как правило "вылавливаются" запросы, которые являются лидерами по использованию ЦПУ,по объемам выполнямых(i/o), перекомпиляциям планов выполнения и много чему еще. Скорее всего эти запросы и будут кандидатами для тестирования. Другое дело, что моделируются то операции и для того чтобы понять в какие операции эти запросы входят (и как эту операцию правильно выполнить) все равно надо будет встречаться и обсуждать с заказчиком. Равно как может быть, что, например, операция - лидер по количеству логических вводов-выводов но с точки зрения бизнеса не критична, делается вне времени обслуживания клиентов. Так что можно попадать и пальцем в небо.
Ну ладно, пошли дальше.Обязательно надо будет снять значения счетчиков мониторинга серверов, входящих в систему (загрузке ЦПУ, памяти, i/o). По этой информации понять есть ли еще где "узкости", на каких серверах. Например видим перегрузка на сервере приложений, ок, смотрим какой сервер приложений используется. Например, Веб Лоджик (ну или Веб сфера), снимаем счетчики очередей, число запросов, ожидающих обработки, число обработанных запросов и т.д. Это все тоже информация для обсуждения с разработчиками заказчика. На основании поведения этого Веб лоджика также можно будет определить операции, приводящие к этим проблемам с перегрузками. Если приложение является Веб приложением, то конечно надо снять картину изменения интенсивности хитов в секунду в течение суток на Веб сервере. Расспросить о том, есть ли какие логи самого приложения. Например, может по этим логам можно понять картину сколько пользователей авторизуется в системе в единицу времени, понять типовые действия этих пользователей в течение дня и т.д. Хотя, в любом случае нужен какой то хотя бы минимальный контакт со специалистами заказчика...Ну и понятно, что при таком исследовании уйдет значительно больше времени на подготовку тестирования.
2.Приложение находится в разработке и тестируют потому что хотят понять что получат в результате
Статистику в этом случае собрать нельзя так как нет самой эксплуатации, стенд видимо существует пока только у девелоперов. Ну.. тогда надо идти в подразделения бизнеса, у них должны быть ожидания сколько рабочих мест будет в организации или сколько пользователей хотелось бы привлечь на веб портал. Так же, бизнес специалисты как правило могут выдать ожидания какие именно операции будут ключевыми, сколько их должно быть в течение суток и т.д. чтобы бизнес окупился, они должны это считать!...Побеседовать с разработчиками, они точно могут добавить к вырисовывающейся картине в каких операциях ожидаются сложные "тяжелые" запросы...
В крайнем случае можно, конечно, самому посмотреть статистику по аналогичным Веб или бизнес приложениям.
Автор: Андрей, В 11 февраля 2009 г. в 13:39
Резюме все таки такое... Заказчики не могут не знать свое ПО (в большинстве случаев). У них есть специалисты, прекрасно разбирающиеся во многих аспектах, касающихся работы приложения, которое мы хотим протестировать. Возможно они хотят посмотреть какие шаги будут предприняты специалистами по нагр. тестированию, возможно их спецы в данный момент очень заняты... Но если в этих случаях начать исследовать программное приложение самому и задавать дальше уже вполне конкретные и предметные вопросы то помощь должна быть оказана так как без этой помощи тоже трудно обойтись...
Автор: Андрей, В 11 февраля 2009 г. в 13:45
Андрей, спасибо... В принципе чем-то подобным мы и занимаемся сейчас - исследуем ПО. Но заказчик ставит задания типа (дальше цитата):
1. The solution must be able to accommodate at least 200 concurrent users
2. The majority of operations must have a response time of less than 6 seconds at peak
load. Average response time must be no more than 2 seconds.
и плюс этому:
- Минимальная ширина интернет-канала на стороне клиента 256 кбит/сек, на стороне сервера 10 Мб/с
Больше ничего он не сообщает. Признаться честно это не моя задача, я всего лишь помогаю старым коллегам из Минска. И постепенно мне начинает казаться, что он просто специально дает не полные данные, чтобы проверить специалистов минской компании :)
Короче, я пока просто даю советы как и что им делать и что узнавать у заказчика, т.к. нагрузочное тестирование не является их прямым профилем.
Вот.
Автор: А.Б., В 12 февраля 2009 г. в 05:48
Наконец добились хоть чего-то:
• 2 million unique users per month
• 15 million page views per month
:))) уже можно хоть что-то, хоть поверхностно думать и делать :)
Автор: А.Б., В 12 февраля 2009 г. в 07:19
Ага.. а просмотр страниц это и есть основная операция (судя по статистике речь идет о веб приложении:-))? Есть ли еще поиски, регистрации, покупки?
1. Я бы постарался понять какие операции выполняет пользователь, если у пользователей есть несколько ролей то составил бы что то вроде списка "роль - операции". Сделал бы это на основе документации и своего предметного понимания области бизнеса. Пусть этот список будет стартовой точкой для обсуждения.
2. Отправил бы это понимание заказчику с просьбой уточнить или поправить.
Ну и далее надо получить статистику по тем операциям которые останутся в списке на тестирование, статистику вроде той какую они приводят пусть за месяц... Значит статистика все таки собирается. Надо потом только еще эту статистику проанализировать на предмет понимания сколько операций делается в единицу времени во время пиковой нагрузки..
Автор: Андрей, В 13 февраля 2009 г. в 05:50
Я тебя поражу сейчас еще раз.
1. Все железо и софт стоят на стороне заказчика. Доступ к ним через только инет.
2. База данных практически пустая.
3. тестировать надо:
а) Логин - логаут
б) Логин - клик по ссылке Вопросы - логаут
в) Логин - поиск - Логаут
все условия описаны мной выше...
И это вытягивали из заказчика почти неделю, и то благодаря тому, что спрашивали правильные вещи :)
Ну как можно работать спокойно?
А вдвойне обидно, что такого рода задания дают людям без опыта.
Автор: А.Б., В 13 февраля 2009 г. в 12:15
ищу хостинг http://hosting.miheeff.ru хостинг ищу хостинг
Автор: hosting.web.hosti, В 25 декабря 2009 г. в 08:59
Отправить комментарий
Подпишитесь на каналы Комментарии к сообщению [Atom]
<< Главная страница