В настоящее время информационные системы превратились из вспомогательных научных инструментов в центральные компоненты современной цивилизации. В постиндустриальном обществе, за редким исключением, жизнь каждого человека прямо или косвенно связана с ними. Управление, профессиональная деятельность, обучение, развлечение и т.д. уже немыслимы без информационных систем, являющихся сосредоточением информации – ценнейшего ресурса нашей цивилизации. По этой причине к их надежности предъявляются чрезвычайно высокие требования.
Высокое качество работы информационных систем обеспечивается за счет тестирования. Тестирование представляет собой процесс исследования системы с целью проверки соответствия ее работы предъявляемым требованиям. Существует большое количество разнообразных видов тестирования, охватывающих различные аспекты. Для информационных систем глобальной сети одним из наиболее важных видов тестирования является нагрузочное. Его целью является проверка функционирования и сбор характеристик в условиях, близких к эксплуатационным.
Нагрузочное тестирование является сложным процессом, включающим множество шагов. Усилия исследователей в настоящий момент сосредоточены на вопросах создания тестов [3–5, 9, 11, 12], разработки нагрузочных моделей [14], а также анализа полученных результатов [8, 15]. Есть работы, посвященные разработке методик нагрузочного тестирования распределенных систем [2]. В то же самое время вопросам запуска тестов и сбора результатов уделяется недостаточное внимание. При их решении полагаются на программные средства для нагрузочного тестирования. Несмотря на их многообразие, все они обладают одинаковыми недостатками. В большинстве случаев при использовании одного компьютерного узла создать достаточную величину нагрузки не удается. Это обусловлено множеством аппаратных и программных факторов. Поэтому применяют совокупности соединенных компьютеров, представленных в виде распределенных, кластерных и облачных вычислений. Таким образом, нагрузочное тестирование информационных систем требует подключения большого количества компьютеров и дополнительных затрат. На преодоление этих недостатков и повышение интенсификации процесса направлена наша работа.
Стадия запуска тестов представляет собой процесс создания нагрузки на целевую систему и сбор метрик производительности на основе анализа ответов. При этом нагрузка представляет собой множество тестовых запросов, отправляемых с большой интенсивностью. Процесс отправки запроса можно разделить на 2 части:
● в соответствии с тестовыми скриптами осуществляется генерация запроса, который затем передается операционной системе;
● операционная система обеспечивает передачу и доставку запроса на тестируемую систему.
При этом время, необходимое операционной системе на обработку и передачу запроса, определяет предельную величину интенсивности, которую может достичь компьютерный узел. Таким образом, эта величина является нагрузочной способностью компьютерного узла. В нашей работе [1] мы провели эксперименты с целью измерения данной величины на популярных ОС. В ходе экспериментов была выявлена следующая особенность. На каждый тестовый запрос исследуемая система формирует ответ, который подвергается анализу. Ввиду того, что в ходе нагрузочного тестирования создается большая нагрузка, на нагружающую систему направляется большой поток ответов. Проведенные эксперименты позволили обнаружить, что этот поток ответов снижает нагружающие способности узла. В нашей работе мы назвали данную особенность эффектом обратной нагрузки.
Для интенсификации стадии запуска тестов и сбора результатов мы предлагаем иной подход. Он основан на применении специализированного аппаратного блока, построенного на базе ПЛИС, который исполняет функции операционной системы по доставке сообщений. Он создает нагрузку и собирает метрики производительности. При этом подготовка тестовых запросов и параметров осуществляется с помощью компьютерного узла. После передачи этих данных на аппаратный нагрузчик он обеспечивает передачу запросов с требуемой интенсивностью и собирает необходимые метрики производительности.
На основе этой идеи был спроектирован прототип устройства, названный нами – аппаратный нагрузчик информационной системы (АНИС). Он был построен на основе платы разработки Terasic De2-115 с ППВМ ПЛИС Altera Cyclone IV [6]. На рис. 1 представлена обобщенная схема прототипа.
Ключевые компоненты, необходимые для генерации пакетов и обеспечения их доставки, реализованы в устройстве аппаратно. В состав АНИС также входит процессорная система, назначением которой является конфигурация параметров и обеспечение загрузки тестовых запросов. Ввиду того, что плата разработки содержит ограниченный набор памяти, собираемые метрики производительности выгружаются через отдельный интерфейс на компьютер. Для выгрузки данных АНИС содержит клиент базы данных Redis [13]. Таким образом, результаты нагрузочного тестирования оказываются в базе данных Redis, которая находится на отдельном компьютере. При разработке прототипа учитывались недостатки существующих систем. Так, обработкой исходящих и входящих данных занимаются независимые блоки, поэтому эффект обратной нагрузки на АНИС не проявляется. Ранее нами были проведены измерения предельных характеристик прототипа. Они показали высокие характеристики АНИС. Так, на формирование одного пакета с запросом устройству необходимо в среднем 220 нс. В данной статье представлены результаты испытания прототипа для создания нагрузки на веб-сервер.
Для испытания применялись узлы со следующими характеристиками:
● экспериментальная платформа (ЭП) № 1, компьютер Intel Core i7 920 2,67 ГГц, DDR3-1066 9ГБ, CentOS 6.4;
● экспериментальная платформа № 2, ноутбук Samsung R580-JS03 Intel Core i5 430 M 2,26 ГГц, DDR3-1066 3 ГБ, Ubuntu 12.10;
● экспериментальная платформа № 3, ноутбук MacBook Air Intel Core i7 3667U 2 ГГЦ, DDR3L-1600 МГц 8 ГБ, OS X 10.8.5.
В качестве нагружаемых систем выступали экспериментальные платформы 1 и 2 с установленным веб-сервером NGINX [10]. После установки веб-сервера, настройки и дополнительные модули были оставлены без изменений. В ходе ответа на запрос он формировал стандартную html страницу. Результаты работы прототипа сопоставлялись с результатами широко используемого в настоящее время инструмента нагрузочного тестирования Apache JMeter [7]. Источником информации о созданной нагрузке служат лог файлы сервера, в которых регистрируется каждый поступивший запрос и его время.
Рис. 1. Структура разработанного прототипа
Инструмент нагрузочного тестирования запускался сначала на одной экспериментальной платформе, а затем на другой. Кроме того, параметры программы Jmeter на каждой платформе определялись эмпирическим путем так, чтобы создаваемая нагрузка была наибольшей. Результаты испытаний представлены на графиках (рис. 2 и 3).
Рис. 2. Испытание прототипа аппаратного нагрузчика на экспериментальной платформе № 1
Рис. 3. Испытание прототипа аппаратного нагрузчика на экспериментальной платформе № 2
Представленные графики демонстрируют, что опытный прототип в ходе испытаний создавал кратковременную значительную нагрузку с некоторой периодичностью. Проведенный анализ данных, полученных с помощью перехватчиков пакетов, показал, что это связано с высокой интенсивностью генерации запросов прототипом. Во время создания нагрузки устройство отправляло запросы веб-серверу и ожидало ответа от него в пределах сессии. Как показывают данные перехватчика пакетов, сервер получал запрос, но не всегда отвечал на него. Ввиду того, что в составе текущей версии прототипа отсутствуют механизмы таймеров, устройство бесконечно долго ожидало ответа от сервера. Через некоторый промежуток времени, определяемый настройками веб-сервера и операционной системы, информационная система разрывала соединение с прототипом, полагая, что запросов с его стороны не поступило. Получив запрос на разъединение, аппаратный нагрузчик перезапускал соединение и продолжал отправлять запросы. По этой причине временные промежутки между всплесками примерно одинаковы. Кроме того, как видно на графиках, пиковое значение интенсивности с каждым всплеском уменьшалось. Причиной этого явился тот же эффект, только в этом случае сама операционная система не отвечает на запрос открытия TCP сессии.
Проведенные испытания продемонстрировали практические возможности прототипа АНИС. Даже несмотря на недостатки текущей версии, полученные результаты показывают, как с помощью аппаратного модуля с ПЛИС возможно интенсифицировать процесс создания нагрузки и сбора результатов. Таким образом, прототип способен стать полноценным инструментом для задач нагрузочного тестирования.
Рецензенты:Корольков А.В., д.ф.-м.н., профессор, декан ФЭСТ, ФГБОУ ВПО «Московский государственный университет леса», г. Мытищи-5;
Финогеев А.Г., д.т.н., профессор ка федры «Системы автоматизации проектирования», ФГБОУ ВПО «Пензенский государственный университет», г. Пенза.
Работа поступила в редакцию 28.11.2014.