AJAX (Asynchronous JavaScript and XML) — технология веб-программирования, ставшая популярной с тех пор, как ею начали пользоваться разработчики таких сервисов, как eBay, Amazon и Google Maps. Сегодня активно обсуждаются технологии тестирования инструментариев Ruby on Rails, Selenium и AJAX.net, но с учетом того, что основная причина стремительного роста популярности AJAX — высокое быстродействие, выглядит странным практическое отсутствие дискуссии о методах тестирования производительности AJAX-приложений. Перечислим ряд специфических сложностей, возникающих при таком тестировании.

AJAX и обычные веб-приложения

На рис. 1 сопоставляются модели традиционного веб-приложения и AJAX-приложения. Традиционное работает следующим образом: пользователь выполняет действие в браузере (набирает URL, нажимает на ссылку или заполняет форму), браузер отправляет к веб-серверу запрос URL и в ответ получает страницу. Затем браузер отправляет дополнительные запросы на загрузку внедренных в страницу объектов, например изображений, отображает страницу с внедренными ответами и ждет следующего действия пользователя. Здесь важно то, что, во-первых, браузер запрашивает сразу всю страницу и она обновляется целиком. Во-вторых, запросы браузера являются прямым последствием действий пользователя.

Рис. 1. Модели приложений: а — в традиционном веб-приложении запросы к серверу и ответы поступают в синхронном режиме, на каждый запрос сервер формирует страницу целиком и отправляет браузеру; б — в приложении AJAX запросы и ответы асинхронны, по запросу загружается только определенный участок страницы
Рис. 1. Модели приложений: а — в традиционном веб-приложении запросы к серверу и ответы поступают в синхронном режиме, на каждый запрос сервер формирует страницу целиком и отправляет браузеру; б — в приложении AJAX запросы и ответы асинхронны, по запросу загружается только определенный участок страницы

 

Приложения AJAX асинхронно совершают по нескольку запросов для разных участков текущей страницы. Эти запросы отправляются программой, работающей на клиентской стороне (в браузере). Код такой программы, обычно реализованный на JavaScript, называется движком AJAX. Циклов многократной полной загрузки страниц, как в традиционных веб-приложениях, здесь уже нет, благодаря чему приложения AJAX больше похожи на программы для настольных ПК — вместо полных страниц у сервера запрашиваются лишь небольшие фрагменты данных. Благодаря этому уменьшается объем данных, пересылаемых по сети, пропускная способность расходуется оптимальнее и повышается «отзывчивость» приложения. Но если приложение AJAX не оптимизировано, то эффект может быть противоположным — например, если движок отправляет слишком много запросов, он увеличит, а не уменьшит нагрузку на сеть.

В современных веб-приложениях AJAX применяется практически повсеместно. И речь не только о функционально сверхнасыщенных приложениях вроде Google Maps или Yahoo Mail — даже на простых сайтах вроде google.com применяются сложные функции AJAX. На рис. 2 показан реальный пример общей функции автозавершения ввода в приложении AJAX.

Рис. 2. Пример веб-приложения AJAX. Движок AJAX сам определяет временные интервалы для совершения асинхронных запросов
Рис. 2. Пример веб-приложения AJAX. Движок AJAX сам определяет временные интервалы для совершения асинхронных запросов

 

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

Традиционное нагрузочное тестирование

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

Для данного метода характерны несколько проблем. Например, при первоначальной записи в файлах cookie могут сохраниться значения, привязанные к индивидуальным сеансам, а также параметры состояния форм, требующие последующей подстройки. Для стандартных веб-приложений данная методика тестирования достаточно действенна, но с появлением AJAX возникли сложности, поскольку теперь браузер исполняет больше логики и хранит больше данных о состояниях. Теперь простая регистрация трафика не всегда дает полную картину происходящего — чем богаче функциями приложение, тем сложнее становится точно имитировать эффекты одновременного обращения сотен или тысяч пользователей к сайту.

Трудности тестирования быстродействия AJAX-приложений

Разберем сложности, связанные с тестированием приложений AJAX, а также методы, метрики и инструменты такого тестирования.

Проблема определения целей и метрик

Цели тестирования производительности приложений AJAX и метрики будут иными, нежели для традиционных приложений [1]. Стандартные параметры, оцениваемые в случае веб-приложений (число просмотров страницы в единицу времени и количество переходов по ссылкам в единицу времени), для AJAX смысла не имеют [2]. Теоретически пользователь может смотреть на одну и ту же страницу часами, не переходя по ссылкам, не заполняя форм и не обновляя ее, но за это время могут быть сгенерированы десятки тысяч запросов. Пример такого приложения — информационная панель мониторинга химического завода: она может сама обновляться через регулярные интервалы, а от пользователя на протяжении длительного времени не поступит ни единого «щелчка». И наоборот — некоторые цели и метрики тестирования быстродействия AJAX могут быть абсолютно неприменимы к приложениям, не пользующимся этой технологией, таким как клавиша возврата на предыдущую страницу, системы речевого воспроизведения содержимого экрана и т. д. [3].

Оптимизация движка AJAX

При разработке традиционных приложений необходимо заботиться, чтобы все серверные компоненты были грамотно спроектированы, настроены и оптимизированы, но движок AJAX действует в качестве промежуточного «сервера» на клиентской стороне — например, если вы вводите строку в поле поиска Bing, Google или Amazon, то движок заранее загружает определенное количество слов и фраз, подходящих к набранному вами тексту. Вы можете выбрать один из предложенных вариантов запроса, что ускоряет и упрощает процесс поиска. Сама идея отличная, но при ее реализации возникают проблемы. Например, движок AJAX может сделать слишком много запросов и тем самым создать излишнюю нагрузку на сеть и веб-сервер. А если запросов будет слишком мало, функция не будет «успевать» за пользователем, особенно если он набирает достаточно быстро. Таким образом, для оптимизации движка разумно варьировать частоту запросов AJAX в зависимости от скорости сетевого соединения и быстроты набора.

Оптимизировать придется многие параметры: уровень использования пропускной способности, объем вычислений на клиенте и сервере, отзывчивость приложения и т. д. Но какие бы критерии ни были выбраны, оптимизация движка AJAX — неизменно важнейшая цель тестирования быстродействия приложений AJAX. Тестировщик сможет выяснить, какая функция в конкретный момент определяет частоту отправки запросов движком AJAX, с учетом времени отклика сервера и скорости печати пользователя. Эту функцию необходимо будет оптимизировать, а характер такой оптимизации зависит от конкретного приложения.

Кросс-платформное быстродействие

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

Имитация пользователя

Моделирование работы пользователя для приложений AJAX существенно отличается от моделирования для традиционных приложений. Для обычных приложений вы записываете различные сценарии, меняете их с расчетом на тестирование под нагрузкой (например, путем рандомизации очередных запросов) и учитываете разное время «обдумывания» пользователем очередного шага. Это описание сильно упрощено, но суть в том, что в случае традиционных приложений действия пользователя влияют только на частоту отправки запросов, а с AJAX дело обстоит по-иному. В частности, содержание запросов AJAX, отправляемых веб-приложением, может меняться в зависимости от того, быстро или медленно пользователь набирает текст. Другими факторами, оказывающими влияние на систему, являются скорость соединения, быстродействие браузера и характер самих поисковых запросов.

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

Подход и инструменты

В ходе проведенного авторами исследования был идентифицирован ряд методов и инструментов, полезных для тестирования приложений AJAX под нагрузкой, которые, помимо устранения прочих проблем с быстродействием, помогают уменьшить количество HTTP-запросов, сделанных вашим приложением, выявить проблемы с вводом/выводом на накопители, проанализировать сетевой трафик, идентифицировать ненужные вызовы и уменьшить расход памяти.

Подход. Можно предложить несколько высокоуровневых подходов к тестированию производительности приложений AJAX. Один из них — тестирование по принципу «черного ящика», когда имитируются действия пользователей в браузерах. Акцент здесь следует сделать на контроле стабильности и времени отклика. Лучше всего воспользоваться выделенной тестовой средой — запросы генерируются динамически с использованием «долгоиграющего» тестового сценария, соответствующего реальной рабочей нагрузке. Обязательно нужно измерять время отклика на стороне конечного пользователя, а также собирать для анализа журналы операций и метрики ОС, полученные в разных условиях.

Инструменты. Плагин Firebug для браузера Firefox полезен не только для выявления ошибок скриптов и получения информации о запросах XMLHttpRequest, но и для контроля времени загрузки различных ресурсов, например скриптов и изображений. Расширение Google Load Time Analyzer, в свою очередь, позволит наглядно сопоставить время загрузки элементов страницы с помощью диаграмм. Плагин YSlow анализирует веб-страницы, отмечая причины замедлений на основе критериев, приведенных в правилах разработки высокопроизводительных сайтов от компании Yahoo.

Tsung — распространяемый в открытых кодах мультипротокольный инструментарий распределенного нагрузочного тестирования, позволяющий имитировать действия пользователей для тестирования масштабируемости и быстродействия клиент-серверных приложений, работающих по IP. Tsung можно применять в том числе для нагрузочного и стресс-тестирования HTTP-серверов с исполняемыми на них приложениями AJAX. Установив Tsung на несколько клиентских машин, можно имитировать работу тысячи виртуальных пользователей, работающих одновременно по различным сценариям.

***

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

Литература

  1. E.J. Weyuker, F.I. Vokolos. Experience with Performance Testing of Software Systems: Issues, an Approach, and Case Study // IEEE Trans. Software Eng. — 2000, vol. 26, — N. 12. — P. 1147-1156.
  2. M. Dhote. Introduction to Cloud Computing Performance Testing // Lambert Academic. 2012.
  3. R. Jain. The Art of Computer System Performance Analysis. John Wiley & Sons, 1991.

Маниш Раджендра Дхоте (edhote@yahoo.com) — ведущий технический специалист подразделения Cisco Systems Mobile Internet Technology Group. Дж. Дж. Сарате (ggsanshu@gmail.com) — профессор Государственного политехнического института Амравати (Индия).

Manish Rajendra Dhote, G.G. Sarate, Testing Complexity Analysis on AJAX-Based Web Applications, IEEE Software, November/December 2013, IEEE Computer Society. All rights reserved. Reprinted with permission.

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF