Home

Автор: Комендантов Илья, компания "Lohika" (г. Одесса)

Самое медленное звено определяет скорость работы всей системы. Утверждение появилось задолго до создания Всемирной Паутины, однако пример использования веб-систем более чем показателен. Наверное, сложно найти человека, который посещает Интернет и ни разу не сталкивался с медленным открытием страниц.

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

Поиск "узкого места" - нетривиальная задача. Отдельно модули системы могут работать без видимых отклонений, а производительность системы при этом оказывается далека от желаемой. Проблему интеграции можно описать словами Задорнова: "...по отдельности вы совершенно нормальные ребята! Но когда вместе – это буквально всероссийское бедствие, причем вечное". Коварство слабых звеньев ещё и в том, что при небольшой нагрузке, проявляются только грубые ошибки интеграции, лежащие на поверхности. В реальной жизни начинают сбоить даже те места системы, которые никак не проявлялись ранее. Часто такое поведение связано с проблемами в архитектуре. Нетрудно представить последствия глобальных изменений на финальных стадиях разработки.

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

1. Загрузить систему вручную.

Неоправданно дорогое удовольствие: подготовить рабочие места, найти людей (десятки тысяч, иногда сотни и более), синхронизировать их усилия, как-то собрать и проанализировать результаты. Этот метод стоит рассматривать лишь в экзотических случаях.

2. Заказать тестирование специализированной фирме.

Допустим это не шарашкина контора, а вполне себе достойная организация, в таком случае:

• Качество тестирования будет на высоком уровне.
• Будут предоставлены все необходимые отчёты по работе системы под нагрузкой.
• Сделаны предположения о слабых местах.
• Какой-то дополнительный сервис.

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

3. Воспользоваться бесплатным инструментом нагрузочного тестирования.

Плюсы - очевидны, из минусов - нет никакой гарантии результатов, отсутствие поддержки заказчика (support), работает чаще всего только http.

4. Написать свою программу для нагрузочного тестирования.

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

Минусы - сложность создания, необходимость тестирования самого инструмента, его поддержка.

5. Купить готовый инструмент нагрузочного тестирования.

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

Последний вариант наиболее распространённый в кругу мало-мальски серьёзных фирм, единственная проблема - выбор фирмы-производителя.

К моменту написания статьи (2011 год) на рынке присутствует более чем достаточно инструментов нагрузочного тестирования, в том числе именитых брэндов: LoadRunner (Hewlett-Packard), Rational Performance Tester (IBM), SilkPerformer (Borland).

Все инструменты по-своему хороши, но в HP LoadRunner 11 появился протокол, на который хочется обратить особое внимание. Его можно назвать уникальным и даже долгожданным в области нагрузочного тестирования. Но давайте обо всём по порядку.

В начале 90-х (первый официальный релиз 1989г.) израильская фирма Mercury Interactive вошла на рынок с уникальным для тех времён продуктом - LoadRunner (LR), который долгое время является лидером в области нагрузочного тестирования.

Историческая справка: в 2006 году Hewlett-Packardкупила MercuryInteractive. Сейчас полное название - HPLoadRunner.

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

Эта возможность реализуется линейкой web-ориентированных протоколов. Сначала LoadRunner позволяет записать сценарий взаимодействия пользователя с приложением. При записи LoadRunner создаёт прокси (используется механизм хукинга http://en.wikipedia.org/wiki/Hooking), через который и происходит общение клиент-сервер. На этапе кодогенерации другой механизм воссоздаёт последовательность действий пользователя. Готовый скрипт проигрывается при помощи встроенного браузера.

Основные web-протоколы:

WindowsSockets. «Слушает» трафик и записывает активность в виде полученных и отправленных буферов. Пишет данные уровня TCP/IP «как есть». Подобие сниффера.

WebHTTP/HTML. Самый популярный протокол. Работает в двух режимах:

1. URL-based – задействует «HTTP traffic analyze» механизм, который интерпретирует каждый буфер в термины HTTP-протокола (URLs).

2. HTTP-based – находит источники HTTP-запросов, используя HTML-парсер. Скрипт получается более понятный для пользователя.

WebClickandScript. К HTML-парсеру добавили механизм, «понимающий» DOM, а также Scripting Engine (JavaScript). В результате LoadRunner генерирует скрипт, ориентированный на объекты браузера и отображающий бизнес-процесс пользователя в ещё более понятном виде.

Однако развитие технологий web 2.0 создаёт трудности при записи и проигрывании web-скриптов (разумеется, проблемы возникают во всех инструментах, не только в LoadRunner). Всё бОльшая часть операций выполняется на стороне клиента и прослушивание трафика ничего не даёт. Вдобавок, встроенный в LoadRunner браузер требует дополнительных усилий на его доработку и поддержку. По сути, чтобы проигрывать скрипты, записанные даже для средненьких web 2.0 сайтов, необходимо создавать полноценный браузер, реализующий все современные стандарты и технологии, используемые в веб-разработке.

Для поддержки конкретных технологий в LoadRunner появились новые протоколы: Ajax (Click and Script), Flex, Silverlight, но по-прежнему ситуация с web 2.0 сайтами до недавнего времени оставалась под вопросом. Многие порталы представляют собой смесь технологий, при записи которых возникают проблемы.

Решением стал принципиально новый протокол – Ajax TruClient. Он появился в 11-й версии LoadRunner (осень 2010).

Историческая справка: Один из программистов HPполностью разработал концепцию работы нового протокола, способного нагружать web 2.0 сайты, и сам же реализовал его на практике! Решение получилось настолько удачное, что в данный момент созданы отдельные команды для его развития и улучшения. Тестировался протокол в двух странах (Израиль, Украина), причём на каждого программиста (подключившиеся где-то в середине разработки), приходилось по несколько тестировщиков для охвата огромного количества современных web 2.0 сайтов.

Ajax TruClient выглядит как отдельный продукт, интегрированный в LoadRunner, и довольно сильно отличается от любого другого web-ориентированного протокола.

Он, как и предшественники, эмулирует действия пользователя в браузере, но:

• Скрипт записывается интерактивно - теперь пользователь видит результат каждого действия сразу же, не ожидая окончания записи бизнес процесса и кодогенерации. Может удалять шаги, перезаписывать, проигрывать без необходимости прерывать бизнес-процесс.
• Ajax TruClient разрабатывался специально для javascript-ориентированных сайтов с поддержкой технологии Ajax.
• Протокол основан на новом подходе автоматического распознавания объектов и для записи использует новый механизм.
• На данный момент протокол работает с Mozilla Firefox (версия поставляется вместе с LoadRunner), проигрывание скриптов происходит на "живом" браузере.

Конечно, как всякий молодой инструмент, Ajax TruClient не лишён недостатков - производительность протокола сильно зависит от записываемого сайта, пока что поддерживаются не все технологии, записывается только Firefox.. Однако всё это с лихвой перекрывается преимуществами и огромным потенциалом возможностей нового протокола:

• Трёхуровневая интерактивная запись
• Группировка шагов, альтернативные шаги;
• Конструкции for, if, break, continue, catch error;
• Функции: проверки, ожидания объекта;
• Выполнение кода: JavaScript, C, большой список поддерживаемых API-функций;
• Идентификация объектов: Automatic, Xpath, JavaScript;

Ajax TruClient - новый для LoadRunner подход в нагрузочном тестировании web 2.0. Он чем-то смахивает на Windows 7 – красивый, удобный, простой в использовании. Эта простота, соединённая с возможностями лёгкой и тонкой настройки скриптов,избавит тестировщиков от титанических усилий, которые необходимы для эмуляции поведения web-приложения с богатым пользовательским интерфейсом традиционными средствами.

Обсудить в форуме