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

[van]

Коллеги, доброго всем времени суток!

Тучи сгущаются, и, судя по всему, придется мне скоро занятся проведением на проектах нагрузочного тестирования :)

Если честно, то я давно ждал этого момента - надо расширять свой профессиональный экспириенс :)
Речь идет о тестировании WEB - приложения.

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

1. Характер нагрузки. Т.е. чем будем нагружать систему: пользователями (при фиксированном объеме данных), данными (при фиксированном количестве пользователей) или их комбинацией.

2. Какие результаты необходимо получить. В каком виде их представлять.

Цитирую с http://www.oracle.co...ad_test_it.html
Response vs Time (resources) - отклики по времени, загрузка ресурсов
Performance - производительность, время отклика
Compare Performance - сравнение производительностей

3. На каких конфигурация проводить тестирование (тестовой или промышленной).

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

А теперь ВОПРОС :)
Поделитесь пожалуйста личным опытом в данном виде деятельности.
Что я пропустил?
На что еще следует обратить внимание?

Вобщем, жду Ваши мысли по этому поводу.

Заранее всем премного благодарен!

[van]

Попытался сам ответить на свои вопросы. Закопался по самые уши :)
Вот, что нашел (огромный кладезь опыта и знаний):
http://www.qaforums....ic;f=2;t=000901

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

А ссылочка, наверняка, поможет кому - то еще кроме меня.

[Олешка]

Ой-ей... та же песня. Все что могу:

1. Характер нагрузки. Т.е. чем будем нагружать систему: пользователями (при фиксированном объеме данных), данными (при фиксированном количестве пользователей) или их комбинацией.

При работе с моим тулом (WAPT) получается только пользователями грузить. Насчет данных - не поняла идею. Если поясните, будет замечательно. Данные придется гонять по сети, пропускной канал ограничен, сеть ляжет раньше, чем приложение. Разве что поднимать сервер приложений на той же машине, что и тул - тогда сеть исключена из цепочки. И не забывать о логгировании - это тоже ресурс машины. Обычно проводим следующие типы тестов: performance - определение критической нагрузки, load - работа под критической нагрузкой долгое время, и stress - работа за пределами критической нагрузки.

2. Какие результаты необходимо получить. В каком виде их представлять.

Я меряю время отклика (response time) и отслеживаю, при каком числе одновременных пользователей оно становится больше чем допустимо.
Дополнительно, как выяснилось в недавнем тесте, приходится отслеживать полноту доставки страниц. Загрузку сервера не смотрю, ибо нечем, ну разве что top, sap. Но там не очень удобный вывод данных.

3. На каких конфигурация проводить тестирование (тестовой или промышленной).

Идеально - на промышленной, перед поставкой, естессно. Но это для web-приложений редко достижимо, дорогое оборудование очень.

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

Да, и во вторую - от средств мониторинга и анализа результатов.

Что я пропустил?

Load balancing и нагрузочное с применением IP spoofing.

Мысли, хм. Мне вот интересно, как народ мониторит сервер приложений, кроме его переделки (мы сниффер добавляли к Tomcat).

[Олешка]

Есть хорошая книга: "Производительность Web-служб. Анализ, оценка и планирование. Метрики, модели, методы." Авторы - Дэниел Менаске, Виргилио Алмейдо. Сайт книги тут.

[Олешка]

Еще вспомнила к выбору тула. Не все тулы позволяют определять точки рандеву - момент, когда резко возрастает нагрузка на определнную функциональность приложения. Может пригодиться. Правда, те что позволяют, вроде как стоят запредельно.

[Dmitry_NJ]

Мысли, хм. Мне вот интересно, как народ мониторит сервер приложений, кроме его переделки (мы сниффер добавляли к Tomcat).

Зависит от сервера приложений. Например, WebLogic умеет сам рассказывать о своих performance counters через JMX (или SNMP, если WebLogic ниже 6-ой версии). Ваше дело - только выбрать counters, которые вам интересны. С WebSphere похожая история.

[Dmitry_NJ]

Не все тулы позволяют определять точки рандеву - момент, когда резко возрастает нагрузка на определнную функциональность приложения. Может пригодиться. Правда, те что позволяют, вроде как стоят запредельно.

Зависит от ваших пределов :)

[van]

Спасибо за участие.

Уточнил проблему: в первую очередь стоит задача тестирования нагрузки на сервер БД (в нашем случае Oracle), о тестировании web - сервера пока вопрос не стоит.

[van]

У кого - нибудь был подобный опыт?

[Dmitry_NJ]

Уточнил проблему: в первую очередь стоит задача тестирования нагрузки на сервер БД (в нашем случае Oracle), о тестировании web - сервера пока вопрос не стоит.

Все равно непонятно. Если у вас 3-х звенная архитекура с web сервером и Oracle back-end, то по-любому вам надо тестировать web приложение, даже если вам все равно что происходит с вашим web сервером. Соответственно протокол, с которым будете работать - HTTP(S). Отсюда и выбор инструментов шире, включая и бесплатные. Если у вас обычное клиент/серверное приложение, при котором клиент гонит на сервер SQL траффик, то и протокол (SQL) совсем другой и выбор инструментов сильно ограничен (про бесплатные вообще не слышал).

[Олешка]

Не все тулы позволяют определять точки рандеву - момент, когда резко возрастает нагрузка на определнную функциональность приложения. Может пригодиться. Правда, те что позволяют, вроде как стоят запредельно.

Зависит от ваших пределов :)

Пределы у нас маааленькие. А тулы стоят очень дорого. За такие деньги дешевле нанять толпу студентов. ;)

[shiny]

Уточнил проблему: в первую очередь стоит задача тестирования нагрузки на сервер БД (в нашем случае Oracle), о тестировании web - сервера пока вопрос не стоит.

Совсем недавно встала проблема за очень короткий срок (2 дня) дать приблизительную оценку performance нашего приложения (3-х уровневое: веб-клиент, веб-сервер, oracle). Пришлось в срочном порядке изучать тулы для этого вида тестирования. Выбрали SilkPerformer - вещь очень неплохая (хоть все его ньюансы и не успели познать). Во-первых, позволяет сам записывает скрипты для воспроизведения на "понятном языке"; во-вторых, имеется возможность задать различные варианты нагрузки; ну и, в-третьих, очень хороший репорт (по крайней мере нам статистики хватило).
Так вот, при первом запуске скрипта была картина, когда веб-сервер почти простаивал, а oracle прямо таки валился. Исходя из результатов немного поправили структуру бд (добавили индексы на поля, по которым ведется частый поиск) -этим немного повысили performance- и получили картину, когда уже веб-сервер был загружен на 100%, а oracle работал в привычном режиме. Сейчас девелоперы решают эту проблему.
Я хочу сказать, что не обязательно выделять при нагрузочном тестировании отдельно сервер бд и сервер приложений. Тест сам покажет, где у вас узкое горлышко...

Мысли, хм. Мне вот интересно, как народ мониторит сервер приложений, кроме его переделки (мы сниффер добавляли к Tomcat).

Веб-сервер WebSphere, его мониторили с помощью таск менеджера :))

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

[Dmitry_NJ]

Веб-сервер WebSphere, его мониторили с помощью таск менеджера :))

SilkPerformer что не умеет WebSphere мониторить? :blink:

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

И без проведения тестов это настолько же очевидно, насколько очевидно, что надо чистить зубы.

[Олешка]

Совсем недавно встала проблема за очень короткий срок (2 дня) дать приблизительную оценку performance нашего приложения (3-х уровневое: веб-клиент, веб-сервер, oracle). Пришлось в срочном порядке изучать тулы для этого вида тестирования.

У нас так же. Эта засада со короткими сроками уже начинает утомлять. :(

Выбрали SilkPerformer - вещь очень неплохая (хоть все его ньюансы и не успели познать). Во-первых, позволяет сам записывает скрипты для воспроизведения на "понятном языке"; во-вторых, имеется возможность задать различные варианты нагрузки; ну и, в-третьих, очень хороший репорт (по крайней мере нам статистики хватило).

Когда я смотрела WAPT, у меня было такое же впечатление. Если можно, более развернуто - что такое понятный язык - запись скрипта с GUI? Какие варианты нагрузки там возможны? Какие характеристики можно измерять? Есть ли графика? Можно ли просмотреть отчеты по конкретным пользователям? И, если можно, хоть в приват - поделитесь, сколько стоит SilkPerformer?

Взамен расскажу про свой, если интересно.

[van]

Дамы и господа!
Если информация не конфиденциальная, почему бы не написать ее прямо здесь...
Думаю, что она будет очень полезна всем заинтересованным лицам.

Так что пишите здесь, не стесняйтесь :)

[van]

shiny, а каким образом измерялосьпроизводительность оракла? какие именно метрики Вы использовали?

данную информацию дает сам SilkPerformer, или приходится Task Manager на оракловом серваке изучать? :)

[yurigaga]

Если архитектура:
Oracle DB server - Application server (BackEnd) - Web Server (FrontEnd)
То можно тестировать следующим образом:
- Создать большую базу данных (т.е. DB Inflate) 1 000 000 entries
как ? в каждом случае свой способ ( можно и при помощи LoadRunner)
- Тестировать нагрузку на FrontEnd при помощи LoadRunner
т.е. Web VUser
- Тестировать нагрузку на BackEnd при помощи LoadRunner
т.е. EJB VUser
При таком тестировании можно определить где пробки
используя различные мониторы которые есть в LoadRunner

А если использовать последную версию LoadRunner 8
то там есть новая примочка Diagnostic Breakdown Module.
Который разбивает Response Time по различным слоям:
Web Layer, JNDI Layer, EJB Layer, JDBC Layer
Которые в свою очередь могут быть разбиты
на классы, методы и даже SQLs.
И здесь уже будет видно точно в каком конкретно
классе и методе больше всего теряется время.

Юрий

[Dmitry_NJ]

А если использовать последную версию LoadRunner 8
то там есть новая примочка Diagnostic Breakdown Module. Который разбивает Response Time по различным слоям...

Ну Diagnostic Module применительно к J2EE платформе не такой уж и новый. J2EE Diagnostics (J2EE Transaction Breakdown) module существовал еще в LR 7-oй версии. Diagnostics в LR 8.0, конечно, позволяет делать больше, чем J2EE Diagnostics module (в частности опуститься до уровня конкретного SQL запроса, генерируемого определенным bean'ом). Ну и архитектура к тому же изменилась (унифицировали J2EE probe для LR, Business Availability Center и Deep Diagnostics, ранее известный как OptiBench; для LR/BAC добавили mediator server, обрабатывающий данные от probe и посылающий их дальше в LR/BAC). Что действительно нового появилось в LR 8.0 Diagnostics так это поддержка аналогичного breakdown для Siebel и Oracle. A LR 8.0 FP1 добавляет еще диагностику и для .NET платформы.

[AlexLek]

Если у вас 3-х звенная архитекура с web сервером и Oracle back-end, то по-любому вам надо тестировать web приложение, даже если вам все равно что происходит с вашим web сервером. Соответственно протокол, с которым будете работать -  HTTP(S). Отсюда и выбор инструментов шире, включая и бесплатные.

Если возможно, подскажите где эти бесплатные (и не бесплатные но подешевле :) )
искать ( в моём случае HTTPS)
и какие тулы ,кроме LoadRunner, позволяют разбивать нагрузку по слоям ?

[Dmitry_NJ]

Если возможно, подскажите где эти бесплатные (и не бесплатные но подешевле :) ) искать ( в моём случае HTTPS)

OpenSTA - бесплатный тул, но я не в курсе работает ли он с HTTPS.

и какие тулы, кроме LoadRunner, позволяют разбивать нагрузку по слоям?

Из бесплатных точно никакие.