В применении к тестированию Internet-приложений часто употребляют термины load testing («нагрузочное тестирование») и stress testing («стрессовое тестирование») [1,2,9]. Первый термин обозначает измерение производительности системы в условиях ожидаемой нормальной загруженности, а при стрессовом тестировании уровень нагрузки превышает возможности системы по обслуживанию пользователей. Стрессовое тестирование позволяет определить минимальные величины ресурсов, необходимых для работы приложения, оценить предельные возможности системы (скажем, максимальное число пользователей или максимальную плотность потока запросов) и обнаружить факторы, ограничивающие эти возможности (т.е. найти «узкие места» системы). Кроме того, целью стрессового тестирования может являться обнаружение ошибок в серверном приложении, а также тестирование способности системы к сохранению целостности данных в аварийных ситуациях и к восстановлению после таких ситуаций. Оба типа тестирования часто объединяют под общим наименованием performance testing («тестирование производительности»).

Характеристики работы серверов и реалистичность тестирования

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

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

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

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

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

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

Средства тестирования Web-серверов

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

Стандартные тестовые наборы

В группу стандартных тестовых наборов входят SPECweb99 от Standard Performance Evaluation [4], WebBench компании eTestingLabs [5], WebStone, разработанный MindCraft [6], а также TPC-W от Transaction Processing Performance Council [7]. Первые три пакета позволяют измерять производительность сервера в ответ на запросы статических HTML-страниц или динамического содержимого, генерируемого с помощью CGI-скриптов или API-интерфейса Web-сервера (ISAPI или NSAPI). Поддерживается обработка запросов с использованием SSL. TPC-W в большей мере предназначен для тестирования систем электронной коммерции и потому включает доступ к базам данных, а также позволяет оценить показатель цена/производительность.

Общий подход, реализованный в рассматриваемых средствах, включает установку в тестируемой информационной системе стандартного содержимого — HTML-страниц, CGI-скриптов и т.д. Это позволяет получать унифицированные показатели производительности различных аппаратно-программных платформ и сравнивать их возможности между собой. В случаях, когда требуется оценка производительности и настройка конкретной информационной системы, такой подход неприменим.

Microsoft Web Application Stress Tool

Это относительно простое приложение [8] для среды Windows распространяется бесплатно. Тестовый сценарий может быть создан вручную или записан с помощью Web-браузера и затем отредактирован. Для каждого запроса фиксируется запрашиваемый URL и время предварительного ожидания (delay, think time). Уровень нагрузки (stress level) регулируется путем задания количества нитей, осуществляющих запросы к серверу. Задается также число сокетов на нить (stress multiplier). Общее число сокетов, которое в данной системе также интерпретируется как число виртуальных пользователей, равно произведению числа нитей на число сокетов, открытых каждой из нитей:

Total Concurrent Requests =
 Stress level (threads) x Stress multiplier =
 Total Number of Sockets

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

Среди возможностей Web Application Stress Tool: аутентификация виртуальных пользователей и пользовательских сеансов; передача данных с использованием протокола SSL; возможность группирования URL и задания относительной доли запросов для каждой группы; использование для тестирования Web-сервера нескольких централизованно управляемых клиентских машин. К недостаткам можно отнести отсутствие возможностей статистической обработки результатов тестирования.

OpenSTA

OpenSTA — приложение с открытым кодом для платформ Windows [2]. Как и Web Application Stress Tool, оно позволяет создавать тестовые сценарии при помощи браузера на специализированном языке Script Control Language. Для облегчения редактирования тестовых сценариев можно использовать инструментарий Script Modeler. Поддерживается аутентификация пользователей и установления соединений по протоколу SSL. Основное внимание при разработке данного средства было уделено применению распределенной обработки и открытых стандартов, в частности CORBA. Распределенная обработка повышает реалистичность тестов и дает возможность тестирования высокопроизводительных систем, например, решений для электронной коммерции. В случае распределенной системы одна из машин (repository host) осуществляет сбор и хранение результатов; кроме того, на каждом из узлов тестирующей системы выполняется сервер имен OpenSTA name server. Каждый из узлов распределенной тестирующей системы выполняет свою группу заданий (task group), описываемую сценарием или набором сценариев. Результаты тестирования, включающие времена откликов и коды ответа для каждого запроса, представляются в табличной или графической форме.

PureLoad

Система тестирования компании Minq Software [9] представляет собой Java-приложение и поддерживает платформы Windows, Sun Solaris, Red Hat Linux. Существуют версии PureLoad Enterprise и PureLoad Web (предназначена для тестирования только Web-серверов). PureLoad Enterprise поддерживает протоколы IMAP/POP3, FTP, JDBC и др., предоставляя дополнительные возможности по программированию пользовательских заданий (PureLoad Tasks) с использованием PureLoad Task API. Поддерживаются безопасные соединения с использованием SSL и пользовательские сеансы. Реалистичность имитации пользователей повышается путем обработки поступающих с сервера данных и генерации динамически изменяемых параметров. Управление системой осуществляется посредством консоли PureLoad Console.

Каждому виртуальному пользователю соответствует легковесный процесс, так называемая «рабочая нить» (worker thread). Виртуальные пользователи исполняют задания, объединенные в сценарии. Сценарии описываются в формате XML и могут быть созданы с использованием браузера (модуль PureLoad Web Recorder) или при помощи «паука» (PureLoad Web Crawler), обходящего все доступные документы на сервере.

Рис. 1. Распределенная архитектура PureLoad

Для создания нагрузки PureLoad может использовать распределенные вычисления. Каждый из узлов вычислительной системы, осуществляющей тестирование сервера, исполняет «рабочий процесс» (worker process), которому соответствует копия виртуальной машины Java. Каждый рабочий процесс порождает определенное число рабочих нитей. Управление рабочими процессами осуществляется посредством «менеджеров» (manager process) — серверных процессов, запускаемых по одному на каждый узел. Выделяется также узел Task Space Server, осуществляющий параметризацию сценариев, подготовленных с помощью консоли администрирования, и распределение их между рабочими процессами (рис. 1).

 

Рис. 2. Графическое сопоставление результатов тестирования с помощью PureLoad Result Comparer

Результаты тестирования могут быть представлены в графической форме, сохранены в формате HTML или в текстовой форме для дальнейшей обработки с помощью инструментов сторонних производителей. Результаты нескольких тестирований можно сопоставить между собой с помощью утилиты Result Comparer (рис. 2).

 

Apache JMeter

Apache JMeter [10] — инструментарий с открытым кодом, реализующий ряд интересных решений. Как и PureLoad, JMeter представляет собой Java-приложение. JMeter предназначен для тестирования не только Web-серверов и их отдельных компонентов (сервлеты, CGI-сценарии), но также и FTP-серверов и баз данных (с использованием драйвера JDBC). При условии установки дополнительных пакетов шифрования (например, Java Secure Sockets Extension) возможна поддержка SSL. Предусмотрены механизмы авторизации виртуальных пользователей; поддерживаются пользовательские сеансы.

 

Рис. 3. Jmeter — графическое представление значений времени отклика (Data), средних значений (Average) и стандартного отклонения (Deviation) с помощью слушателя GraphResults

Для каждого виртуального пользователя JMeter порождает нить. Сценарий поведения пользователя («план тестирования») задается последовательностью HTTP-запросов. На текущий момент отсутствует возможность создавать сценарии поведения пользователей при помощи браузера. Управление запросами осуществляется с помощью модулей, называемых контроллерами, а доступ к данным тестирования производится с помощью слушателей. Каждый слушатель собирает информацию, относящуюся только к одной определенной группе виртуальных пользователей. Собранную информацию можно представить в текстовой форме с помощью слушателя File Reporter или в виде графика с помощью слушателя Graph Results (рис. 3). При этом производится и первичная статистическая обработка результатов. Интервалы времени между запросами задаются с помощью таймеров.

 

Одним из достоинств JMeter является возможность удаленного тестирования с использованием клиент-серверной архитектуры на основе механизма Java RMI. Генерация нагрузки и сбор данных осуществляются на одном узле сети, а обработка и визуализация данных на другом, что минимизирует влияние параметров среды передачи данных на результаты измерений. Клиент-серверная архитектура дает возможность построения распределенной системы тестирования путем размещения независимых тестирующих компонентов JMeterEngines на узлах вычислительной сети и удаленного управления ими.

Еще одно достоинство JMeter, упрощающее обработку результатов тестирования, — это возможность использования тестовых утверждений (assertion). Ее наличие позволяет автоматически проверять соответствие ответов сервера, полученных в ходе тестирования, ожидаемым величинам. Например, с помощью тестовых утверждений, записанных в форме регулярных выражений, можно проверить наличие определенного текста в HTTP-ответе. Использование Java не только обеспечивает поддержку большого числа платформ и облегчает построение распределенных систем, но также способствует расширяемости данной системы тестирования. Развитию JMeter способствует и доступность исходных текстов; это позволяет надеяться на повышение качества данного инструментария в будущем.

Существенным недостатком имитации поведения пользователей в JMeter является отсутствие поддержки случайных интервалов времени между запросами и независимых интервалов ожидания (think time) для различных URL.

LoadRunner

Инструментарий LoadRunner компании Mercury Interactive [11] предназначен для анализа производительности информационных систем уровня предприятия. Этим продиктовано наличие ряда особенностей, отсутствующих у уже рассмотренных систем. Так, LoadRunner поддерживает тестирование большого числа сетевых инфраструктур и их компонентов, включая Web-серверы, базы данных, компоненты COM, JavaBeans, виртуальные машины Java и т.д. Это делает LoadRunner ценным инструментом для анализа работы гетерогенных сетевых сред, типичных для большинства крупных информационных систем. Важным свойством с точки зрения анализа работы бизнес-приложений является и возможность отслеживания выполнения транзакций.

Еще одно качество, необходимое для системы тестирования такого класса, — масштабируемость для создания высоких уровней нагрузки, которая в LoadRunner достигается путем использования распределенных вычислений, а также технологии TurboLoad, минимизирующей использование центрального процессора тестирующего компьютера каждым из виртуальных пользователей. Благодаря этому система из 10 высокопроизводительных серверов может формировать нагрузку, эквивалентную нескольким сотням тысяч пользователей или миллионам запросов в день.

Тестирование Web-приложений, как и в большинстве других систем аналогичного назначения, основано на использовании сценариев, описывающих последовательность действий виртуальных пользователей. Поддерживаются соединения с использованием SSL. Сценарии описываются в формате XML и могут быть созданы с использованием браузера, а также при помощи специальной утилиты Virtual User Generator.

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

Сбор и представление результатов тестирования в реальном времени осуществляются с помощью мониторов, являющихся аналогом слушателей в JMeter. Предусмотрены мониторы для определения параметров производительности вычислительной сети предприятия в целом, отдельных сетевых устройств, операционных систем, а также распространенных сетевых приложений: IIS, Apache, iPlanet, Oracle, DB2, SQLServer и др. LoadRunner предоставляет возможность измерения множества параметров (в том числе, количество виртуальных пользователей, число обрабатываемых запросов в секунду, время ответа, количество завершенных аварийно транзакций).

LoadRunner представляет собой мощный инструмент для тестирования крупных информационных систем, однако его применение для небольших Web-серверов и баз данных вряд ли оправдано, учитывая высокую стоимость: лицензия для 50 виртуальных пользователей стоит 40 тыс. долл.

QALoad

Инструментарий QALoad компании Compuware [12] позволяет измерять производительность Web-серверов, FTP-серверов, серверов баз данных, а также распределенных систем, построенных на основе CORBA. Возможно тестирование систем, поддерживающих SSL и цифровые сертификаты. Кроме того, QALoad позволяет анализировать работу унаследованных систем, использующих алфавитно-цифровые терминалы, например, VT100. Схема тестирования типична для большинства систем аналогичного назначения: измерение производительности осуществляется на основе сценариев, которые могут быть созданы путем записи трафика, генерируемого приложением. Возможное число виртуальных пользователей достигает сотен тысяч. Анализ получаемых результатов может проводиться в процессе тестирования, кроме того, предусмотрен экспорт данных для их последующего анализа при помощи программных пакетов сторонних разработчиков.

QALoad представляет интерес как приложение для тестирования серверов, позволяющее осуществлять одновременное наблюдение за внутренними параметрами тестируемой системы. Как и LoadRunner, QALoad реализует концепцию мониторов, производящих слежение за одним из измеряемых параметров. Однако в случае QALoad мониторы получают данные с тестируемой системы посредством агентов. Программное обеспечение, необходимое для установки агентов и удаленного слежения за параметрами работы приложений, входит в состав другого пакета компании Compuware, ServerVantage [13], который интегрирован с QALoad. Предусмотрены агенты для широкого спектра вычислительных платформ, операционных систем и приложений: Solaris, Windows, Linux, Novell Netware, IIS, IBM DB2, Microsoft SQL Server, Oracle и др. Набор измеряемых параметров также довольно широк и включает использование центрального процессора, памяти, параметры сетевых соединений, базы данных и т.д. Поддерживается наблюдение за параметрами тестируемой системы через Internet.

Метод сбора данных, основанный на использовании устанавливаемых агентов, обладает и очевидными преимуществами и недостатками. К достоинствам можно отнести полноту получаемой информации о тестируемой системе и возможность сопоставления параметров ее производительности и внутренних характеристик. Кроме того, исключается влияние среды передачи данных на измерение временных интервалов между событиями, происходящими в тестируемой системе. Среди недостатков — искажение результатов измерений под влиянием самих устанавливаемых агентов, поскольку они потребляют ресурсы вычислительной системы. Однако в случае высокопроизводительных систем, на анализ работы которых ориентирован QALoad, этим можно пренебречь.

Общие подходы к тестированию Web-серверов

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

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

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

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

Так, при выборе инструмента тестирования производительности нужно помнить, что процесс настройки Web-сервера с целью достижения оптимальных параметров функционирования может потребовать многократного прогона тестов, поэтому система тестирования должна обладать возможностями по обработке результатов тестов, их хранению и сравнению. Уровни этих возможностей для рассмотренных систем различаются. Microsoft Web Stress Tool не предоставляет даже средств графического отображения данных, в то время как PureLoad и LoadRunner позволяют производить анализ и сравнение данных в графическом режиме. Подход, основанный на использовании независимых друг от друга программных модулей, каждый из которых осуществляет наблюдение за одним из параметров (мониторы в LoadRunner и QALoad, слушатели в JMeter), представляется оптимальным, поскольку позволяет собирать и обрабатывать только необходимые данные, а также выбирать способ их представления.

***

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

Сергей Рогов (sirogov@yahoo.com) — сотрудник Гуманитарного центра содействия внешнеэкономической деятельности и международным связям; Дмитрий Намиот (dnamiot@yahoo.com) — старший научный сотрудник лаборатории открытых информационных технологий ВМиК МГУ (Москва).

Литература

  1. Siegfried Goschl, Microsoft Web Applications Stress Tool. JUGAT Meeting, 12 Junе 2001, www.javausergroup.at/events/was.pdf

  2. OpenSTA Documentation. Open System Testing Architecture Organization, www.opensta.org/docs/index.html

  3. Е.С. Вентцель, Исследование операций. М.: "Советское радио", 1972

  4. SPECweb99. Standard Performance Evaluation Corporation, 1999, www.spec.org/osd/web99/docs/whitepapers.html

  5. WebBench 4.1 Overview. eTestingLabs, 2001, www.etestinglabs.com/benchmarks/webbench/home.asp

  6. WebStone 2.x Benchmark Description. Mindcraft, 1998, www.mindcraft.com/webstone/ws201-descr.html

  7. Леонид Черняк, Снова о тестах TPC. // Открытые Системы, 2000, № 11

  8. Aaron Ching, Pedro Silva, Allen Wagner, Performance Testing with the Web Application Stress Tool. Microsoft Developer Network, January 2001

  9. PureLoad Web User's Guide. Minq Software, 2002, www.minq.se/ products/ pureload/ doc/ html/ web/ usersguide/ index.html

  10. JMeter User's Manual. Jakarta Project, 2002, jakarta.apache.org/jmeter/usermanual/index.html

  11. Илья Бромберг, Автоматизация тестирования. // Открытые Системы, 2002, № 5

  12. QALoad Product Detail. Compuware, 2002, www.compuware.com/products/qacenter/qaload/detail.htm

  13. ServerVantage Product Detail. Compuware, 2002, www.compuware.com/products/vantage/servervantage/detail.htm

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