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

[Genka]

Всем привет.

Заранее прошу прощения, что не слишком глубоко вдавался в поиск, но времени очень мало, а вопрос несколько специфический.

Итак, есть веб приложение, пишущееся на ASP.NET 2. Используется cms Sitecore и поисковый движок FAST. Нужно нагрузить приложение хотя бы двумя сотнями юзеров одновременно, чтобы посмотреть, как оно себя поведет при такой нагрузке.

И тут кроется вот какая западня. Движок FAST кеширует запросы. Если сделать такой же запрос во второй раз - он просто отдает кешированные данные и, соответственно, никакой нагрузки на него не происходит. Т.е. нужно варьировать поисковые данные случайным образом.

По запросам типа "web stress/load tool" и т.п. гугл выдает сотни решений (если не тысячи, блин), а времени - ну вы знаете, как оно бывает, надо было сделать вчера.

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

Пробовал MS Web Stress Tool, но она не позволяет варьировать запросы для каждого юзера отдельно.

Вот как-то так. Любые идеи, советы, предложения очень нужны.

Заранее спасибо

[dlg99]

Вот как-то так. Любые идеи, советы, предложения очень нужны.

TestComplete, скорее всего, использует единожды записанный ViewState. Для сайтов на Asp.Net, использующих ViewState нужно этот самый стейт 'синхронизировать' между запросами. Вот что нашлось с первой попытки: http://blog.falafel....stComplete.aspx

Еще можете попробовать Visual Studio Team Systems 2005/2008 (если оно у Вас есть, лучше 2008) - там есть Web Load Testing. VSTS синхронизирует Viewstate автоматически.
параметры на вход можно подцепить из базы/csv файла либо использовать C# и генерировать что угодно.

Я его не очень много использовал, но для простых случаев там все очень просто.
Всякие потенциально полезные ссылочки, если пойдете этим путем:

http://blogs.msdn.co...tsloadtestblog/
http://blogs.msdn.co...bar-issues.aspx
http://social.msdn.m...ebtest/threads/
http://blogs.msdn.com/joshch/
http://blogs.msdn.com/edglas/
http://codeplex.com/TeamTestPlugins
http://blogs.msdn.co...les/528649.aspx

Еще - FAST у вас локально установлен? Там, скорее всего, кэш можно или отключить или очень сильно уменьшить.

[Genka]

Спасибо за ответ.

У ТестКомплита есть возможность обновлять ViewState автоматически для контролов, которые пользователь сам перечисляет. Естественно, все эти контролы были включены (их 4 вместе с ViewState).

Студия нужная есть, сейчас начну копать.

FAST установлен на отдельном сервере и при записи скрипта никак не участвует в процессе. Кроме того, я тут посмотрел внимательно в логи ФАСТа и понял, что дело не в нем (по крайней мере на данном этапе). Так как даже закешированные запросы попадают в логи ФАСТа, однако в случае воспроизведения скрипта никаких изменений в логи не попадает, а вот редирект на страничку ошибки происходит с завидным постоянством.

[Troubleshooter]

Jmeter может сделать то, что вам нужно.
Другой вопрос это наличие у вас времени разобраться с самим тулом и реализовать нужный вам сценарий.

[ncrm]

Jmeter не сложный продукт. Долго разбираться не прийдется. А чтобы не мучаться со сценарием, можно использовать Jmeter в связке с BedBoy.

[Troubleshooter]

Jmeter не сложный продукт. Долго разбираться не прийдется. А чтобы не мучаться со сценарием, можно использовать Jmeter в связке с BedBoy.

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

[ncrm]

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

Параметры задать не сложнее чем в других аналогичных продуктах. А вот использование BedBoy значительно ускоряет работу по созданию скелета скрипта. Чтобы потом в Jmetr'e задать необходимые параметры. Если сценарий не маленький, то ручками в жметре этот самый скелет создвавть большой головняк. ИМХО.

[barancev]

А вот использование BedBoy значительно ускоряет работу по созданию скелета скрипта.

Обращаюсь к грамотным людям -- не просветите, чем BadBoy лучше, чем штатные встроенные в JMeter средства записи?

[Troubleshooter]

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

Параметры задать не сложнее чем в других аналогичных продуктах. А вот использование BedBoy значительно ускоряет работу по созданию скелета скрипта. Чтобы потом в Jmetr'e задать необходимые параметры. Если сценарий не маленький, то ручками в жметре этот самый скелет создвавть большой головняк. ИМХО.

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

[dlg99]

У ТестКомплита есть возможность обновлять ViewState автоматически для контролов, которые пользователь сам перечисляет.
Естественно, все эти контролы были включены (их 4 вместе с ViewState).

В зависимости от приложения, там могут быть еще и другие подобные параметры.
Поройтесь в Fiddler-овских логах для 'реального' юзера и для ТестКомплитовского виртуального.
Возможно, какие-то параметры не коррелированы.

FAST установлен на отдельном сервере и при записи скрипта никак не участвует в процессе.
Кроме того, я тут посмотрел внимательно в логи ФАСТа и понял, что дело не в нем (по крайней мере на данном этапе).

идея была скорее в том, что если MS Web Stress Tool Вас устраивает во всем, кроме того что Вам не обойти ФАСТовский кэш, то можно просто кэш выключить (или сильно уменьшить).