Сервис удалённого тестирования производительности ПО на различных программно-аппаратных конфигурациях

Создать новую статью

Дата последнего изменения :   28.09.2009 01:34
Рейтинг
 


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

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

Введение

Данный сервис участвовал в конкурсе идей по разработке программных сервисов, проводимый Санкт-Петербургским отделением Intel, оказался в числе победителей, и поэтому смысл моего участия в школе сводился к тому, чтобы начать реализовывать этот сервис. Идея сервиса родилась под впечатлением от конкурсов типа Intel® Threading Challenge. Одной из трудностей, с которыми сталкиваются участники, является тестирование своих конкурсных программ на различных многоядерных конфигурациях. Анализ ситуации привёл к пониманию того, что с похожими проблемами сталкиваются и другие люди, а значит, такой сервис может быть востребован.

Что и зачем это, для кого это нужно?

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

Список доступных конфигураций

Рис. 1. Список доступных конфигураций.

Для того чтобы выполнить заявку, клиенту необходимо иметь “часы доступа”, которые могут приобретаться у поставщика сервиса, либо начисляться (с определённым коэффициентом) в том случае, если на конфигурации клиента уже выполнялись задачи других членов сообщества. После приёма заявки она становится в очередь (если данная конфигурация в это время занята выполнением другой задачи), либо сразу начинает выполняться. После выполнения, клиент получает отчет со статистикой загрузки всех ядер, памяти и другой важной с точки зрения производительности информацией (рис.2).

Отчёт о производительности ПО

Рис. 2. Отчёт о производительности ПО.

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

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

Общая концепция сервиса удалённого тестирования производительности ПО

Рис. 3. Общая концепция сервиса удалённого тестирования производительности ПО.

Условно рынок можно поделить на 3 сегмента: компании занимающиеся разработкой программного и аппаратного обеспечения, различные НИИ и вузы, а также индивидуальные разработчики.

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

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

Новизна сервиса

На данный момент в мире существует несколько разработок связанных с удалённым тестированием программного обеспечения, так называемые “cloud computers”. Сервис заключается в том, что поставщик создаёт несколько типичных аппаратных конфигураций, а клиент сервиса имеет возможность загрузить своё программное обеспечение на такие конфигурации и протестировать их производительность. Например, такой сервис предоставляют такие компании как: Amazon EC2, Rackspace cloud, Windows Azure, Google APP Engine.

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

Структура сервиса. Принцип работы.

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

Схема сервиса

Рис. 4. Схема сервиса

Из рисунка 4 следует то, что процесс постановки на выполнение программы происходит в несколько этапов. Таким образом, принцип работы сервиса может быть отображён с помощью нескольких схем. Предположим, что у нас существует сервер, две конфигурации, одна из которых доступна, вторая находится в пассивном режиме, а в сообщество хочет вступить новый пользователь:

Регистрация нового клиента

Рис. 5. Регистрация нового клиента.

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

Новая конфигурация

Рис. 6. Новая конфигурация.

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

Постановка задачи на выполнение и результат

Рис. 7. Постановка задачи на выполнение и получение результата.

Тестирование производительности программного кода

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

Для тестирования производительности в клиентское программное обеспечение был встроен модуль, отвечающий за постановку задачи на выполнение в системе, замер счётчиков производительности и обработку результатов. Для получения значений счетчиков было решено использовать библиотеку PDH (Performance Data Helper), основу которой составляет pdh.dll, интерфейс взаимодействия с которой представлен функциями API.Такой выбор был обусловлен тем, что эта библиотека имеет простой интерфейс взаимодействия и предоставляется компанией Microsoft бесплатно.

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

  • Загруженность процессора должна составлять не более 5 %.
  • От устройств ввода не поступал сигнал более десяти минут.

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

Задача скрытного выполнения программного обеспечения и абстракции от типа приложения также является не тривиальной, так как с одной стороны нам необходимо протестировать приложение незаметно от пользователя конфигурации и в то же время обеспечить тестирование любого типа приложения (например независимо от того имеет оно графический интерфейс или нет). Обе эти проблемы не были решены, так как время на выполнение работы было ограничено одним месяцем. Теоретически же проблема абстракции может быть решена с помощью использования так называемой “обёртки” приложения. Например, для решения проблемы можно предоставить пользователю некую библиотеку, которую член сообщества должен загрузить в тестируемое приложение и используя функции из этой библиотеки имитировать управление программой, в частности эмулировать ввод пользователем различной информации, эмуляции вывода на экран и т.д.

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

Хранение данных

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

Протокол взаимодействия

Протокол взаимодействия систем должен был включать описание взаимодействий:

  • Клиент – сервер
  • Клиент – клиент

Таким образом, протокол разбивался на два интерфейса взаимодействия между системами. Для реализации протокола использовалась технология сокетов, в частности библиотека WinSock2, поставляемая и поддерживаемая компанией Microsoft.
В рамках демонстрационной версии сервиса существовало конечное число различных сообщений, которые должны были обрабатываться различными модулями:

а) Клиент - сервер

  • Запрос на регистрацию (код I)
  • Ответ на регистрацию (код O)
  • Запрос на базу данных (код W)
  • Переход конфигурации в активное состояние(код U поле Status On)
  • Переход конфигурации в пассивное состояние(код U поле Status Off)

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

б) Клиент – клиент

  • Запрос на постановку задачи на выполнение (код M)
  • Отчёт о производительности (код R)

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

Безопасность

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

а) “Песочница”

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

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

б) Виртуальная машина

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

Однако такой метод полностью противоречит концепции сервиса, так как предполагается, что программное обеспечение будет исполняться на реальных аппаратно-программных конфигурациях.

в) Организационные методы

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

О планах

Одним из условий защиты проекта была также подготовка бизнес-плана. Подробно об этом писать здесь, пожалуй, не стоит. Приведу самые интересные факты. Период окупаемости сервиса был оценён в 1,5 года. При этом учитывались аренда офиса, заработная плата для нескольких человек, издержки на раскрутку сервиса и т.д. Стоимость часа доступа к сервису была принята в 1,10$ или 37 рублей.
Пока данный проект реализуется только под OC Windows. И сервер, и клиент пишутся на C++. Пока конечно и интерфейс, и протоколы, и механизмы безопасности далеки от совершенства. Все эти недостатки планируется устранить в ходе дальнейшей работы над сервисом. Также интересны пути увеличения информации, собираемой о тестируемом приложении. Вот здесь, в соседней статье, говорится о том, что Parallel Inspector можно запускать и из командной строки, без MS Visual Studio… Возьму на заметку ;-)

Заключение

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

Об авторе

Шудрак Максим является студентом Сибирского Государственного Аэрокосмического Университета, в городе Красноярске, участвовал в Летней школе компании Intel в городе Санкт-Петербурге. Помимо огромного количества полезной информации, навыков и умений, полученных во время прохождении Летней школы, я познакомился с одним из самых прекрасных городов в мире – Санкт-Петербургом.