И снова нагрузочное тестирование
#1
Отправлено 03 марта 2005 - 15:10
Тучи сгущаются, и, судя по всему, придется мне скоро занятся проведением на проектах нагрузочного тестирования :)
Если честно, то я давно ждал этого момента - надо расширять свой профессиональный экспириенс :)
Речь идет о тестировании WEB - приложения.
В связи с этим, внимательно изучив материалы этого форума (и не только), наметил для себя следующие моменты, на которые необходимо обратить пристальное внимание при внедрении нагрузочного тестирования. Их последовательность может не совпадать с действительностью.
1. Характер нагрузки. Т.е. чем будем нагружать систему: пользователями (при фиксированном объеме данных), данными (при фиксированном количестве пользователей) или их комбинацией.
2. Какие результаты необходимо получить. В каком виде их представлять.
Цитирую с http://www.oracle.co...ad_test_it.html
Response vs Time (resources) - отклики по времени, загрузка ресурсов
Performance - производительность, время отклика
Compare Performance - сравнение производительностей
3. На каких конфигурация проводить тестирование (тестовой или промышленной).
4. Выбор средства нагрузочного тестирования. Его выбор в первую очередь будет зависеть от протокола или протоколов, по которым работает приложение.
А теперь ВОПРОС :)
Поделитесь пожалуйста личным опытом в данном виде деятельности.
Что я пропустил?
На что еще следует обратить внимание?
Вобщем, жду Ваши мысли по этому поводу.
Заранее всем премного благодарен!
#2
Отправлено 03 марта 2005 - 15:52
Вот, что нашел (огромный кладезь опыта и знаний):
http://www.qaforums....ic;f=2;t=000901
Думаю, разгребать все это можно не один месяц, так что все еще жду Ваших советов, опытов и т.п.
А ссылочка, наверняка, поможет кому - то еще кроме меня.
#3
Отправлено 03 марта 2005 - 15:56
При работе с моим тулом (WAPT) получается только пользователями грузить. Насчет данных - не поняла идею. Если поясните, будет замечательно. Данные придется гонять по сети, пропускной канал ограничен, сеть ляжет раньше, чем приложение. Разве что поднимать сервер приложений на той же машине, что и тул - тогда сеть исключена из цепочки. И не забывать о логгировании - это тоже ресурс машины. Обычно проводим следующие типы тестов: performance - определение критической нагрузки, load - работа под критической нагрузкой долгое время, и stress - работа за пределами критической нагрузки.1. Характер нагрузки. Т.е. чем будем нагружать систему: пользователями (при фиксированном объеме данных), данными (при фиксированном количестве пользователей) или их комбинацией.
Я меряю время отклика (response time) и отслеживаю, при каком числе одновременных пользователей оно становится больше чем допустимо.2. Какие результаты необходимо получить. В каком виде их представлять.
Дополнительно, как выяснилось в недавнем тесте, приходится отслеживать полноту доставки страниц. Загрузку сервера не смотрю, ибо нечем, ну разве что top, sap. Но там не очень удобный вывод данных.
Идеально - на промышленной, перед поставкой, естессно. Но это для web-приложений редко достижимо, дорогое оборудование очень.3. На каких конфигурация проводить тестирование (тестовой или промышленной).
Да, и во вторую - от средств мониторинга и анализа результатов.4. Выбор средства нагрузочного тестирования. Его выбор в первую очередь будет зависеть от протокола или протоколов, по которым работает приложение.
Load balancing и нагрузочное с применением IP spoofing.Что я пропустил?
Мысли, хм. Мне вот интересно, как народ мониторит сервер приложений, кроме его переделки (мы сниффер добавляли к Tomcat).
#5
Отправлено 03 марта 2005 - 16:03
#6
Отправлено 03 марта 2005 - 18:09
Зависит от сервера приложений. Например, WebLogic умеет сам рассказывать о своих performance counters через JMX (или SNMP, если WebLogic ниже 6-ой версии). Ваше дело - только выбрать counters, которые вам интересны. С WebSphere похожая история.Мысли, хм. Мне вот интересно, как народ мониторит сервер приложений, кроме его переделки (мы сниффер добавляли к Tomcat).
#7
Отправлено 03 марта 2005 - 18:12
Зависит от ваших пределов :)Не все тулы позволяют определять точки рандеву - момент, когда резко возрастает нагрузка на определнную функциональность приложения. Может пригодиться. Правда, те что позволяют, вроде как стоят запредельно.
#8
Отправлено 04 марта 2005 - 08:06
Уточнил проблему: в первую очередь стоит задача тестирования нагрузки на сервер БД (в нашем случае Oracle), о тестировании web - сервера пока вопрос не стоит.
#9
Отправлено 04 марта 2005 - 10:27
#10
Отправлено 04 марта 2005 - 14:35
Все равно непонятно. Если у вас 3-х звенная архитекура с web сервером и Oracle back-end, то по-любому вам надо тестировать web приложение, даже если вам все равно что происходит с вашим web сервером. Соответственно протокол, с которым будете работать - HTTP(S). Отсюда и выбор инструментов шире, включая и бесплатные. Если у вас обычное клиент/серверное приложение, при котором клиент гонит на сервер SQL траффик, то и протокол (SQL) совсем другой и выбор инструментов сильно ограничен (про бесплатные вообще не слышал).Уточнил проблему: в первую очередь стоит задача тестирования нагрузки на сервер БД (в нашем случае Oracle), о тестировании web - сервера пока вопрос не стоит.
#11
Отправлено 04 марта 2005 - 14:37
Пределы у нас маааленькие. А тулы стоят очень дорого. За такие деньги дешевле нанять толпу студентов. ;)Зависит от ваших пределов :)Не все тулы позволяют определять точки рандеву - момент, когда резко возрастает нагрузка на определнную функциональность приложения. Может пригодиться. Правда, те что позволяют, вроде как стоят запредельно.
#12
Отправлено 05 марта 2005 - 07:47
Уточнил проблему: в первую очередь стоит задача тестирования нагрузки на сервер БД (в нашем случае Oracle), о тестировании web - сервера пока вопрос не стоит.
Совсем недавно встала проблема за очень короткий срок (2 дня) дать приблизительную оценку performance нашего приложения (3-х уровневое: веб-клиент, веб-сервер, oracle). Пришлось в срочном порядке изучать тулы для этого вида тестирования. Выбрали SilkPerformer - вещь очень неплохая (хоть все его ньюансы и не успели познать). Во-первых, позволяет сам записывает скрипты для воспроизведения на "понятном языке"; во-вторых, имеется возможность задать различные варианты нагрузки; ну и, в-третьих, очень хороший репорт (по крайней мере нам статистики хватило).
Так вот, при первом запуске скрипта была картина, когда веб-сервер почти простаивал, а oracle прямо таки валился. Исходя из результатов немного поправили структуру бд (добавили индексы на поля, по которым ведется частый поиск) -этим немного повысили performance- и получили картину, когда уже веб-сервер был загружен на 100%, а oracle работал в привычном режиме. Сейчас девелоперы решают эту проблему.
Я хочу сказать, что не обязательно выделять при нагрузочном тестировании отдельно сервер бд и сервер приложений. Тест сам покажет, где у вас узкое горлышко...
Веб-сервер WebSphere, его мониторили с помощью таск менеджера :))Мысли, хм. Мне вот интересно, как народ мониторит сервер приложений, кроме его переделки (мы сниффер добавляли к Tomcat).
PS При выполнении теста мы поняли одну вещь - проводить нагрузочное тестирование хотя бы для грубой оценки производительности необходимо как можно раньше, т.к. потом возможна ситуация, когда необходимо будет корректировать архитектуру приложения, а это - очень дорогое дело.
#13
Отправлено 05 марта 2005 - 18:39
SilkPerformer что не умеет WebSphere мониторить? :blink:Веб-сервер WebSphere, его мониторили с помощью таск менеджера :))
И без проведения тестов это настолько же очевидно, насколько очевидно, что надо чистить зубы.При выполнении теста мы поняли одну вещь - проводить нагрузочное тестирование хотя бы для грубой оценки производительности необходимо как можно раньше, т.к. потом возможна ситуация, когда необходимо будет корректировать архитектуру приложения, а это - очень дорогое дело.
#14
Отправлено 07 марта 2005 - 09:50
У нас так же. Эта засада со короткими сроками уже начинает утомлять. :(Совсем недавно встала проблема за очень короткий срок (2 дня) дать приблизительную оценку performance нашего приложения (3-х уровневое: веб-клиент, веб-сервер, oracle). Пришлось в срочном порядке изучать тулы для этого вида тестирования.
Когда я смотрела WAPT, у меня было такое же впечатление. Если можно, более развернуто - что такое понятный язык - запись скрипта с GUI? Какие варианты нагрузки там возможны? Какие характеристики можно измерять? Есть ли графика? Можно ли просмотреть отчеты по конкретным пользователям? И, если можно, хоть в приват - поделитесь, сколько стоит SilkPerformer?Выбрали SilkPerformer - вещь очень неплохая (хоть все его ньюансы и не успели познать). Во-первых, позволяет сам записывает скрипты для воспроизведения на "понятном языке"; во-вторых, имеется возможность задать различные варианты нагрузки; ну и, в-третьих, очень хороший репорт (по крайней мере нам статистики хватило).
Взамен расскажу про свой, если интересно.
#15
Отправлено 07 марта 2005 - 11:29
Если информация не конфиденциальная, почему бы не написать ее прямо здесь...
Думаю, что она будет очень полезна всем заинтересованным лицам.
Так что пишите здесь, не стесняйтесь :)
#16
Отправлено 08 марта 2005 - 11:55
данную информацию дает сам SilkPerformer, или приходится Task Manager на оракловом серваке изучать? :)
#17
Отправлено 08 марта 2005 - 14:27
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.
И здесь уже будет видно точно в каком конкретно
классе и методе больше всего теряется время.
Юрий
#18
Отправлено 08 марта 2005 - 15:37
Ну 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 платформы.А если использовать последную версию LoadRunner 8
то там есть новая примочка Diagnostic Breakdown Module. Который разбивает Response Time по различным слоям...
#19
Отправлено 24 марта 2005 - 09:00
Если возможно, подскажите где эти бесплатные (и не бесплатные но подешевле :) )Если у вас 3-х звенная архитекура с web сервером и Oracle back-end, то по-любому вам надо тестировать web приложение, даже если вам все равно что происходит с вашим web сервером. Соответственно протокол, с которым будете работать - HTTP(S). Отсюда и выбор инструментов шире, включая и бесплатные.
искать ( в моём случае HTTPS)
и какие тулы ,кроме LoadRunner, позволяют разбивать нагрузку по слоям ?
#20
Отправлено 24 марта 2005 - 15:10
OpenSTA - бесплатный тул, но я не в курсе работает ли он с HTTPS.Если возможно, подскажите где эти бесплатные (и не бесплатные но подешевле :) ) искать ( в моём случае HTTPS)
Из бесплатных точно никакие.и какие тулы, кроме LoadRunner, позволяют разбивать нагрузку по слоям?
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных