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

[freshment]

Уважаемые коллеги!

Очень рассчитываю на получение не совсем ясного для меня ответа на поставленный вопрос: "как полноценно провести нагрузочное тестирование?"

Из своего опыта тестирования знаю, что одной из основных целей нагрузочного тестирования является получение показателей по ResponseTime, а также последующая их оптимизация.
С помощью различных программ, например LoadRunner, можно записать трафик (бизнес-процессы), спроецировать его на необходимое кол-во пользователей и получить долгожданный ResponseTime по каждой транзакции.
Однако, ResponseTime понятие применимое ко всем функциям разрабатываемой системы, как мне кажется. Например: сама программа тормозит из-за большого кол-ва записей в гриде, или время ожидания ответа от сервера было слишком мало и запрос был прерван и т.д.

Так, насколько я понимаю, одним LoadRunnerom можно измерить ResponseTime зависящий от "Задержки базы" + "Задержки сети". А как же быть с другими критериями, которые зависят от самого клиентского приложения? Правильно ли я понимаю, что нагрузочное тестирование подразумевает также и непосредственное тестирование приложения на возможность работы с большими массивами данных?

Извините, конечно, но может, я чего-то не понимаю?

[Andre]

Добрый день!

Думаю что в двух словах сложно "выдать" методику нагрузочного тестирования, попробую хотя бы обрисовать некоторые важные на мой взгляд моменты :

1. Во-первых на нагрузку как правило тестируется серверное приложение/приложения к которому подключается N-количество клиентов. Работать такие приложения могут в трех или двух звенной архитектуре. Интересно понять какой объем запросов именно этот общий ресурс может "переварить". Поэтому время задержек на клиенте не рассматривается.
(IMHO - "толстый клиент" с большими задержками внутри себя сейчас, при таком развитии распределенных вычислений, уже и не очень актуален, лучше наверное переносить обработку на сервера?)

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

3. На основе требований бизнеса, анализа журналов и т.д. нужно определить объем текущего/прогнозируемого использования этого самого критического функционала в единицу времени, посчитать интенсивность вызовов записанных скриптов, которую надо смоделировать. Эту требуемую интенсивность будет нужно спроецировать на количество вируальных пользователей. (Иногда представители бизнеса, впрочем, сами назвают эти цифры например, они могут попросить проверить одновременную работу 50 - 100 - 2000 пользователей формирующих какой-либо отчет n раз/N sec). На основании этих данных строится групповой сценарий, который может оказаться весьма сложным.

4. Теперь можно поставить счетчики времени внутри скрипта, позволяющие замерить Response time как для одной транзакции, так и для группы транзакций. Безусловно если не используется "transaction break down" то замерено будет все время, включая обработку на серверах приложений, сервере базы данных и т.д, включая и затраты на пересылку данных по сети между компонентами системы. Мне кажется что здесь нужно максимально уменьшить количество неизвестных : в частности сеть и дисковая стойка не должны быть узкими местами. (понять это можно проводя вместе с тестированием Perfomance monitoring ресурсов серверов под нагрузкой)
Если обнаружится что "тормозят" или дисковый массив или сетка то понять поведение приложения вообще очень сложно, нужно по очереди избавиться от этих "узких мест".

5. Также скрипт должен быть параметризирован чтобы каждый VU был "индивидуален" и запросы к общим ресурсам были разными (чтобы уменьшить влияние кеша)

И это, увы, в самых "общих чертах" :).

[SALar]

Из своего опыта тестирования знаю, что одной из основных целей нагрузочного тестирования является получение показателей по ResponseTime, а также последующая их оптимизация.

Это не нагрузочное тестирование. Это тестирование производительности. И получение времени отклика - одна из целей тестирования производительности.
http://forums.softwa...owentry&eid=214

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

Неправильно. Это объемное тестирование.
http://forums.softwa...owentry&eid=223
Не менее важное.

или время ожидания ответа от сервера было слишком мало и запрос был прерван и т.д.

Это один из вариантов стресс тестирования.

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

По разному. Зависит от требований. Это время могут не учитывать, если оно мало.

--------------------------------------
И еще:
http://forums.softwa...812&hl=Объемное

PS. Помогло?

[SALar]

1. Во-первых на нагрузку как правило тестируется серверное приложение/приложения к которому подключается N-количество клиентов. Работать такие приложения могут в трех или двух звенной архитектуре.

А так же однозвенной, четырехзвеенной и 58-звенной.

Поэтому время задержек на клиенте не рассматривается.
(IMHO - "толстый клиент" с большими задержками внутри себя сейчас, при таком развитии распределенных вычислений, уже и не очень актуален, лучше наверное переносить обработку на сервера?)

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

в частности сеть и дисковая стойка не должны быть узкими местами. (понять это можно проводя вместе с тестированием Perfomance monitoring ресурсов серверов под нагрузкой)
Если обнаружится что "тормозят" или дисковый массив или сетка то понять поведение приложения вообще очень сложно, нужно по очереди избавиться от этих "узких мест".

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

Разобраться в проблеме легко. Анализ счетчиков и дополнительные эксперименты легко выявляют узкое место.


---------------------------------------------
Но в целом Andre правильно описал решение.

Советую учесть, что тесты группы "нагрузочные" далеко не для новичков.
И дело вовсе не в сложности использования LoadRunner или аналогичного средства. Сложность состоит в постановке целей, определении критериев успешности и интерпретации результатов.

[freshment]

Вот цитата из довольно граммотно статьи по инструментам для нагрузочного тестирования:

Стрессовое тестирование позволяет определить минимальные величины ресурсов, необходимых для работы приложения, оценить предельные возможности системы (скажем, максимальное число пользователей или максимальную плотность потока запросов) и обнаружить факторы, ограничивающие эти возможности (т.е. найти «узкие места» системы). Кроме того, целью стрессового тестирования может являться обнаружение ошибок в серверном приложении, а также тестирование способности системы к сохранению целостности данных в аварийных ситуациях и к восстановлению после таких ситуаций. Оба типа тестирования часто объединяют под общим наименованием performance testing («тестирование производительности»).

http://www.sibinfo.r...ver_testing.htm

На форумах вычитал следующее:
http://forums.softwa...opic=2067&st=30

Т.е., получается, что тестирование производительности включает в себя и нагрузочное тетсирование и стрессовое тестирование. Действительно, ResponseTime одинаково важен в обоих случаях. Не совсем понятно, а "Объемное тестирование" входит в понятие нагрузочного?

А вот еще цитата из приведенного топика:

Определение критериев загрузки по Microsoft:

Уменьшение responce time является главной целью нагрузочного тестирования - это утверждает Microsoft, и в этом случае я с ними совершенно согласен.

Кстати, приведенные виды тестирования довольно граммотно рассмотрены в RUP:
http://www.cmcons.ru..._rational_3.htm

[Mila]

Не совсем понятно, а "Объемное тестирование" входит в понятие нагрузочного?

Объемное тестирование входит в понятие "тестирование производительности". Эти виды тестов могут существовать сами по себе, входить в сценарии для нагрузочного и стрессового тестирования. Все зависит от тестируемой системы, инструментов, сценариста и т.п.

[freshment]

Спасибо огромное за общие черты методологии!

Для моделирования нагрузки я использую мощную рабочую станцию, есть еще несколько свободных. Как я их могу использовать?
По моим представлениям я могу установить на них тотже LoadRunner и тоже использовать при формировании нагрузки на сервер. Подскажите, как правильно это сделать и как потом интерпритировать полученный результат?

[Dmitry_NJ]

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

Как генераторы нагрузки.

По моим представлениям я могу установить на них тотже LoadRunner и тоже использовать при формировании нагрузки на сервер.

Весь LR на них ставить не надо. Только один компонент нужен - Load Generator.

Подскажите, как правильно это сделать и как потом интерпритировать полученный результат?

Да как обычно. Принципиальной разницы нет сколько у вас LGs в сценарии работало.

P.S. Конкретные технические вопросы по LR обсуждаются в подфоруме по продуктам Mercury. Если по методологии больше вопросов нет, то создавайте новый топик.

[fl1p]

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

Если проскная способность моего канала 10 Мбит, то я смогу сэмулировать только 10 юзеров с пропускной способностью канала 1 Мбит? А про эмуляцию тысячи юзеров и больше я вообще молчу...

Прав ли я?

[Dmitry_NJ]

Правы. Если все 10 юзеров будут без передышки гнать 1 Мбит. Это очень не слабый траффик - видеопоток вполне пристойного качества.

[fl1p]

Тогда как мне сэмулировать, к примеру, 5000 юзеров? Это еозможно вообще, если у меня канал 10 Мб?

[Yury]

Тогда как мне сэмулировать, к примеру, 5000 юзеров? Это еозможно вообще, если у меня канал 10 Мб?

Расширить канал?

[Dmitry_NJ]

Тогда как мне сэмулировать, к примеру, 5000 юзеров? Это еозможно вообще, если у меня канал 10 Мб?

Зависит от того, что делают эти юзеры и как именно. Если у вас главная проблема при тестировании - пропускная способность канала, то прикиньте сколько траффика в среднем генерится одним юзером когда он выполняет те действия и с теми задержками, которые вы эмулируете. И стоит подумать действительно ли все 5000 юзеров должны одновременно генерировать весь этот траффик.