Нагрузочное тестирование для нестандартных протоколов

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

Казалось бы, все просто, берем инструмент для нагрузочного тестирования, записываем трафик, получаем скрипты, проводим тесты – Profit. В теории…

Подходы к подаче нагрузки

Действительно, в большинстве случаев инженеры компании Перфоманс Лаб сталкиваются с тестированием информационных систем, имеющих классическую трёхзвенную архитектуру:

Стандартным подходом при тестировании производительности является эмуляция пользовательского трафика со стороны клиентов на серверную часть. Это работает, но только в том случае если конечные клиентские приложения работают по стандартным поддерживаемым протоколам, таким как HTTP/HTTPS, SOAP, ODBC/JDBC, SAP GUI и некоторым другим.

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

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

То есть задача совсем нетривиальна и вообще не всегда решаема. Фактически, это сродни хакерскому взлому. Скажем так, знатокам в известной телепередаче хотя бы рассказывают наводящую предысторию, а только потом спрашивают, что же находится в чёрном ящике. У вас же даже доступа к предыстории (читай: исходному коду клиентской части приложения) может не быть.

Конечно, можно использовать различные анализаторы трафика (Wireshark, TcpDump и проч.), однако объём трафика может быть настолько значительным, что вам потребуются месяцы для его разбора!

А в нашей практике нередки случаи, когда заказчик вспоминает про нагрузочное тестирование за неделю, полторы до релиза.

А затем ведь ещё нужно написать оболочку так, чтобы она корректно работала с выбранным инструментом подачи нагрузки.

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

Что же делать, если Вы не готовы тратить столько ресурсов на такие длительные изыскания?

Продвинутый нагрузочник, разумеется, сейчас скажет: «Эй ребята, попробуйте CITRIX!»

Использование технологий виртуализации Citrix

Одним из решений задачи является использование продуктов виртуализации Citrix, которое позволяет удаленно получать доступ к приложению практически на любом устройстве. В чём же суть данного подхода?

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

В отличие от первого подхода с «врезкой» инструмента подачи нагрузки на связке клиент-сервер и воспроизведением параметризированного трафика, здесь наш инструмент отправляет команды экземплярам приложения клиента по протоколу ica.

Фактически, мы честно управляем приложениями, через терминальный сервер.

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

Инструменты подачи нагрузки

Наиболее популярным нагрузочным инструментом для работы с протоколом Citrix является продукт компании HP – LoadRunner.

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

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

Наиболее очевидный – стоимость продукта и сложность при расширении функциональности.

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

При этом, наиболее близкий аналог, Apache Jmeter, является полностью бесплатным и легко расширяемым за счет открытого исходного кода и простого, понятного API для написания плагинов.

В общем к чему я это все веду? Да Load Runner хорош, но желание наших заказчиков иметь более бюджетный инструмент подтолкнуло нас к разработке своего плагина к Jmeter для связки с CITRIX, с OCR и синхронизацией.

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

Наше технологическое решение имеет ряд преимуществ над решением от HP.

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

Зная это, при разработке расширения для работы с Citrix большой упор был сделан на реализацию следующих преимуществ:

• гибкости и удобства использования, аналогичных LoadRunner;
• механизмов автоматизация для сокращения времени реализации некоторых сложных алгоритмов непосредственно в сценариях нагрузки;
• интегрированной системы распознавания символов (OCR, Optical Character Recognition), что дает возможность виртуальным пользователям реагировать на любой текст, появляющийся на экране пользователя, и как следствие разрабатывать боле сложные тестовые сценарии.

Ну и напоследок:

Наиболее важное отличие – бесплатность для наших клиентов. Использование Jmeter вместо LoadRunner позволяет значительно сократить расходы, особенно при длительном тестировании, так как для использования HP LoadRunner необходимо закупать лицензии, стоимость которой зависит от количества виртуальных пользователей и длительности тестирования.

Функциональные возможности решения

• Запись действий пользователя (ввод с клавиатуры, нажатие и передвижение мыши) с выбором нужных источников ввода.
• Воспроизведение записанного скрипта.
• Запуск сессии посредством *.ica файлов.
• Запуск сессий с выбранными параметрами (размер области Citrix, глубина цветопередачи).
• Возможность (не)сохранять сделанные скриншоты во время записи/воспроизведения.
• Возможность параметризовать любую команду/параметр в семплерах.
• Возможность указать множитель всех thinktime’ов.
• Возможность запускать сессии без блокировки ввода пользователя.
• Широкие настройки синхронизации.
• Возможность указать (в теории) бесконечное количество хеш-сумм для синхронизации.
• Интегрирован OCR (OpticalCharacter Recognition) движок для распознавания текста.
• Настройка, позволяющая (не)запускать новую сессию при каждой итерации.
• Поддержка Remote Start.

А теперь кратенько расскажем, как оно все работает.

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

Подготовка JMeter

Что нам нужно для работы

Для корректной работы плагина нужно следующее:

• JMeter для работы плагина;
• Библиотека com4j для работы с COM (нужно для плагина, скачать можно здесь);
• JRE x86 версии 7 и выше для корректной работы COM4J и плагина (можно скомпилировать и под JRE 6-й версии);
• Citrix Receiver, через который будет происходить запись и воспроизведение.

Установка плагина

Не стану описывать, как устанавливать JMeter и JRE, думаю, всем это уже знакомо. Установка Citrix Receiver тоже не вызывает трудностей, поэтому перейдем сразу к установке плагина. Для установки самого плагина достаточно скопировать .jar файлы плагина и com4j библиотеки в папку lib в корне JMeter. Но для возможности записи/воспроизведения нужно также добавить запись в реестре (путь приведен для Windows x64, для 32-х разрядных изданий из пути нужно убрать подкаталог Wow6432Node):

Windows Registry Editor Version 5.00

Этот текст можно сохранить в текстовый файл с расширением .reg и добавить запись в реестр, запустив этот файл.

Подготовка к записи

Citrix ICA Recorder

Для записи скриптов нужно добавить в WorkBench элемент Citrix ICA Recorder (находится в категории Non-Test Elements) и указать там правильные параметры подключения:

• ICA file location— путь к файлу .ica для инициализации сессии. Если указан, остальные параметры подключения будут игнорироваться. Можно выбрать через GUI, нажав кнопку Browse;
• Host— адрес сервера;
• Port— порт для подключения. Если не указан, используется стандартный;
• User Name— имя пользователя, которому разрешен доступ к опубликованному приложению;
• User Password— пароль пользователя;
• Domain— домен пользователя, может быть пустым;
• Application— имя опубликованного приложения;

Так же следует настроить параметры записи:

• Save screenshots— если включено, скриншоты, полученные во время записи, будут сохранены;
• Screenshot folder— путь к папке, в которой будут сохраняться скриншоты. Кнопка Browse позволяет выбрать путь через GUI;
• Resolution (WxH)— указывает размер рабочей области Citrix приложения (максимальный размер окна). Указывается в формате <ШИРИНА>x<ВЫСОТА>, разделитель — латинская x;
• Color 24 bit— указывает, какую глубину цветопередачи использовать;
• Record:— указывает, какие события записывать, а какие нет. Возможные варианты: Keyboard — записывать события клавиатуры, Mouse Clicks — записывать нажатия кнопок мыши, Mouse Move — записывать события перемещения курсора мыши;
• Default ICA Config— указывает, какой ICA Config Element использовать в записанных семплерах по умолчанию (об этом будет подробно расписано далее);
• Select controller— указывает, в какой контроллер помещать записанные семплеры;

Запись сессии

После того, как все настройки были введены, можно подключиться к сессии и начать запись. Для включения/выключения записи в рекордере есть группа кнопок Recording controls. Кнопка Connect просто выполняет подключение к сессии. При этом запись не начинается и ее можно включить позже. Кнопка Record подключается и сразу же начинает записывать выбранные действия. Кнопка Stop позволяет остановить запись и отключиться от сессии. При этом сама сессия (окно Citrix Receiver) не закрывается. Так же, при выходе из сессии (например, при закрытии приложения) по событию LogOut происходит автоматическая остановка записи.

Для управления шагами присутствует группа кнопок Step controls. Она становится доступной после включения режима записи. Кнопка Add Step сохраняет текущий шаг и добавляет его в выбранный контроллер. При этом запись начинает происходить в новый семплер. Кнопка Restart Step просто очищает текущий шаг от всех действий (полезно в случае ошибки). Кнопка Start Tag ставит метку, что все команды, записанные до нажатия кнопки End Tag, будут проигнорированы и вместо них будет вставлен текст, введенный пользователем. Кнопка End Tag, соответственно, ставит метку окончания действия команды Start Tag. Кнопка Synchronize делает скриншот всей области Citrix сессии и вызывает диалог настройки синхронизации, на чем я хочу остановиться более подробно.

Синхронизация

На данный момент реализовано 2 варианта синхронизации: по скриншоту и по тексту (путем использования OCR).

Синхронизация по скриншотам

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

• Wait sync— указывает, нужно ли ждать момента, когда будет найдена область с указанным хешом и сколько по времени (максимум) ждать. Второй параметр, try every, указывает, как часто делать проверку. Параметры задаются целыми числами в миллисекундах.
• Delta x, y— указывает, на каком максимальном удалении по ширине и высоте соответственно искать нужную область. Полезно в случаях, если элемент, по которому проводится синхронизация, может незначительно сдвинуться. Но, совершенно бесполезная вещь, если элемент меняет свой размер, т.к. хеш-сумма скриншота будет другой.
• Set sampler error if failed— указывает, помечать ли семплер провалившимся в случае, если за указанное время не удалось найти указанную область. Если не стоит, семплер будет считаться всегда успешным и единственное, как можно будет отличить, появилась ли область или нет, проверять значение переменной, указанной в следующем пункте.
• Write result in variable named— указывает имя переменной, в которую записать успешность синхронизации. На выходе в переменной будет true, если область найдена, иначе false.

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

Синхронизация по скриншотам

Синхронизация по тексту

Для синхронизации по тексту, нужно так же выбрать область экрана, в которой будет распознан текст. Так же необходимо указать два параметра: OCR config handle — строка, указанная в тест-элементе OCR Config в поле OCR Handle (об этом далее), по которой происходит выбор настроенного OCR движка, который будет использоваться для распознавания, и OCR result variable — имя переменной, в которую будет записан результат. В случае, если распознать ничего не удалось, переменная будет создана и инициализирована пустой строкой.

Синхронизация по тексту через OCR

Подготовка к воспроизведению

После записи скрипта, у вас должен получиться тест-план с контроллером и Citrix ICA Sampler’ами внутри. Для воспроизведения сессии необходим как минимум один Citrix ICA Config элемент.

Конфигурация воспроизведения

Внешний вид элемента Citrix ICA Config

Citrix ICA config выглядит очень похожим на Citrix ICA Recorder. У него точно такие же параметры подключения, поэтому описывать их здесь нет смысла, стоит только упомянуть, что все поля в конфигурации подключения могут быть параметризованы, а эти значения будут использованы при инициализации сессии, то есть при выполнении первого попавшегося Citrix ICA Sampler. Например, можно смело использовать CSV Data Set Config для параметризации полей. Поле Citrix Config Handleдолжно быть уникальным для всех таких конфигов. По нему семплеры определяют, какие настройки подключения использовать и подцепляют сессию для продолжения теста.

Настройки воспроизведения сессий отличаются от таковых в рекордере. Остановлюсь на несовпадениях:

• New session each iteration— если указано, при каждой итерации будет создаваться новая сессия. Старая же, если она не закрыта, останется активной, но будет бездействовать.
• Replay mode— если указано, то весь ввод в запущенные сессии будет запрещен. Иначе, пользователь сможет использовать мышь/клавиатуру для ввода данных в открытое приложение. Нужно скорее для отладки.
• Output mode— режим отображения окна. Если указано Normal, окно будет выводиться на экран. Если указано Windowless — окно не будет отображаться, тем самым экономя ресурсы нагрузочных станций (в текущей версии не удалось добиться результата, Receiver игнорирует данную настройку).
• Use sleep times— если указано, все записанные/введенные в ручную задержки будут воспроизводиться. Так же можно указать множитель, на который будут умножаться времена ожидания (только для команд SleepTime).
• Unlock all sessionsи Lock all sessions — разблокирует и блокирует ввод во всех активных сессиях, т.е. меняет параметр Replay mode на «лету». Работает только с теми сессиями, которые запущены на активном JMeter’е и не работает при запуске на удаленных серверах.

Конфигурация OCR

Внешний вид элемента OCR Config

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

• OCR handle— параметр, отличающийся от Citrix ICA Handle лишь тем, что идентифицирует не Citrix ICA Config, а OCR Config. Должен быть уникальным для всех OCR Config.
• Таблица— в левой колонке указывается путь к изображению, с помощью которого происходит обучение, в правой — диапазон символом в изображении (задается в формате <Начальный символ>-<Конечный символ> без угловых скобок и с разделителем в виде тире).

Обучающие изображения — изображение, на котором по порядку отпечатаны символы (можно стройкой, можно таблицей). Обязательное условие — диапазон кодов указанных символов должен быть непрерывен и направлен в сторону увеличения. На каждом изображении должен быть указан лишь один диапазон.

Описание семплеров

Citrix ICA Sampler

Кроме стандартных названия и комментария, Citrix ICA Sampler содержит два поля. Первое — Citrix Config Handle — указывает, какие настройки использовать для запуска сессии или из какого пула взять уже активную сессию. Второе поле содержит список всех команд, которые он будет выполнять. Это поле может быть полность параметризовано с помощью переменных JMeter’а.

Воспроизведение скрипта

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

Советы

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

В случае, если семплеру не удалось получить управление сессией в течении 120 секунд, будет выполнена попытка сделать logout и disconnect сессии в течении еще 60 секунд, после чего автоматически будет предпринята повторная попытка подключения.

Если в редких случаях при синхронизации по скриншотам возникает ошибка — не огорчайтесь, попробуйте добавить хеш-сумму, полученную при воспроизведении, к семплеру (хеш-сумму можно просмотреть на вкладке Response Data в View Results Tree, если при синхронизации произошла ошибка).

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

При использовании клиента Citrix Receiver версии 4.4 и выше, невозможно запустить сессию с «прямыми» параметрами подключения. Только через файлы .ica.

Итоги

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

Если же дело касается тестирования с использованием Citrix, то теперь можно смело говорить, что мы можем это сделать с помощью собственных инструментов не хуже, чем с помощью HP LoadRunner, что может сильно сократить расходы, связанные с тестированием.

Данное расширение является, буквально, «свежим» решением, разработанным в конце 2015 года, но уже хорошо себя показало при тестировании производительности в одном крупном банке.

Сравнение с аналогами не выявило существенных минусов, а если разница минимальна, зачем платить больше?