sukhovam

Разработка универсального теста производительности для
облачных вычислений
В. В. Самыкин, М. А. Макаров, А. М. Сухов
Самарский государственный аэрокосмический университет
Облачные вычисления являются перспективной технологией,
позволяющей централизовать управление вычислительными ресурсами и
оптимизировать их потребление по сравнению с традиционными схемами.
Но в этом случае на первый план выступают такие проблемы, как
производительность самих виртуальных сред и ограничения пропускной
способности сети. В настоящее время широко используются специальные
протоколы доступа к виртуальным рабочим местам, находящимся в
«облаке» [1]. Это RDP (Remote Desktop Protocol), PCoIP (PC over IP
Protocol), RGS и другие. Как показывают исследования, их использование
может дать преимущество при выполнении конкретного сценария клиента.
Однако тесты производительности протоколов VD проводят, обычно, с
применением распространённых офисных, Интернет приложений и
средств мультимедиа.
Поэтому встает вопрос: как измерить производительность и оценить
нагрузку на компоненты «облачной» инфраструктуры в условиях
выполнения тестовых задач, потребляющих значительные ресурсы
системы? В настоящее время не существует универсальной методики
тестирования производительности облачных приложений. В то же время
устоявшиеся области вычислительных приложений, например, системы
высокопроизводительных вычислений, тестируются на основе единых
правил. Существует HPC Challenge Benchmark, набор тестов по
производительности, который и служит платформой для сравнений таких
систем. И хотя тест LINPACK, который лежит в основе системы, имеет ряд
недостатков, тем не менее, преимущества универсального подхода налицо.
Цель данной работы – выработать методику тестирования облачных
протоколов, разработать обобщенный критерий для их оценки, реализовать
программно метод тестирования на основе реальной прикладной задачи.
Основные критерии, по которым должно производиться сравнение – это
производительность серверного процессора, размер оперативной памяти
на сервере и пропускная способность канала связи. Соответственно, тест
должен производить измерения загрузки ЦПУ, ОЗУ и передаваемого по
каналу связи трафика.
Исследование Calyam [2] показало, что производительность
протоколов различается для разных типов обрабатываемых данных. Для
объективной оценки требуется получить комплексный критерий, который
однозначно оценивал бы производительность протокола, а реализующая
его программа выступала в качестве теста производительности
(бенчмарка).
1
Обработка больших массивов данных табличным процессором
хорошо зарекомендовала себя в нагрузке ресурсов, Calyam [2]. Поэтому в
качестве языка для написания тестового ПО был выбран MS Visual Basic, а
в качестве теста - работа с табличными данными в табличном процессоре
MS Excel. Подобные действия сильно нагружают ЦПУ (до 100%) и
занимают большие объемы ОЗУ. Кроме того, передача больших таблиц по
сети обеспечивает большой трафик.
Введем описание основных компонентов тестовой системы.

Прикладная задача – сжатие изображений по алгоритму JPEG
[3].

Входная функция – матрица исходного изображения несжатого
формата.

Основной алгоритм – дискретное косинусное преобразование
(ДКП).

Выходная функция – результирующий поток байт на
окончательное сжатие.

Критерий оценки – комплексный критерий, позволяющий
судить о производительности системы.
Для исследования поведения протоколов облачных вычислений в
реальных условиях была использована специально подготовленная
площадка для экспериментов. Она включает в себя сервера VMware
vSphere, VMware View (Connection Broker), Quest Software vWorkspace
(Connection Broker), два ESX-сервера (Гипервизоры).
За первоначальный критерий оценки скорости выполнения теста
было принято время выполнения основных этапов тестового приложения
на виртуальной машине в облаке на стороне сервера.
Анализируя структуру данного критерия, приходим к выводу, что
главной компонентой является время видео вывода (его вклад 66…90%).
Режим работы, когда видео вывод передается непрерывно на сторону
клиента, назовем «тяжелым» режимом, при ограничениях получим
«легкий» режим. Для «тяжёлых» сценариев полная нагрузка процессора
сочетается со значительной нагрузкой на сеть.
630
383
208
0
100
200
300
RDP Vmware
400
500
RDP Quest
600
700
PCoIP
Рис. 1 – Общее время выполнения теста: набор данных
2
На «лёгких» режимах все протоколы практически одинаковы, но
если посмотреть на временные компоненты для «тяжёлых» режимов, то
разница становится все более очевидной по мере роста нагрузки. На Рис. 1
приведены результаты измерений общего времени выполнения тестовой
задачи для «тяжелых» режимов.
Как видно из Рис. 1, значительное преимущество по времени
выполнения теста имеет протокол PCoIP – 208c против 383c и 630c у
протоколов RDP Quest и RDP WmWare соответственно.
Рассмотрим время отработки основных циклов программы, основой
которой является DCT-преобразование. Как видно из Рис. 2, эта
компонента комплексного критерия примерно одинакова для всех
протоколов (разница колеблется в пределах 8%).
5,44
5,70
5,95
0,00
2,00
4,00
RDP Vmware
6,00
RDP Quest
Рис. 2 – Время выполнения основных циклов преобразования.
На Рис. 3 показан график объёма переданных данных для различных
наборов данных.
16
14
12
10
8
6
4
2
0
0
1
2
PCoIP
3
RDP Wmware
4
5
6
RDP Quest
Рис. 3 – Объём переданных данных (upload) из ВМ в консоль
клиента, Мб
По скорости выполнения операций ввода-вывода несомненным
лидером также является протокол PCoIP – 47,6кБ/с при обсчёте матрицы
коэффициентов размером 48kB.
Говоря о загрузке ЦПУ, следует отметить, что во время передачи
данных на тонкий клиент загрузка процессора становиться скачкообразной
у протоколов семейства RDP, в то время как у PCoIP этого не происходит.
3
Таким образом, у протокола PCoIP процессорные ресурсы при передаче
используются наиболее эффективно.
Для оценки производительности протоколов удобно применять
представление данных в виде диаграмм производительности (Рис. 4) [2].
CPU, %
100
80
60
40
20
0
Net Vср.
RAM %
PCoIP
RDP Quest
RDP Vmware
Рис. 4 – Диаграмма производительности протоколов VDI
Для наглядности за 100% скорости сетевого трафика диаграммы
выбрана скорость передачи данных 400 кбит/с.
Из приведенных диаграмм видно, что такой ресурс, как загрузка
процессоров практически полностью (на 97-99%) используется только
протоколом PCoIP. У протоколов RDP Quest и RDP WMware
среднеинтегральная величина этого показателя составляет 54% и 47%
соответственно. Использование ОЗУ различается незначительно для всех
протоколов. Дальнейшее увеличение загрузки ОЗУ нецелесообразно ввиду
значительного увеличения общего времени прохождения теста. А
пропускную способность сети лучше всего использует протокол PCoIP,
эффективно организуя передачу данных в прямом и обратном
направлениях, что особенно сильно проявляется на тяжелых режимах
тестирования.
Обобщенный критерий, по которому оценивались протоколы,
показывает, что общее время прохождения теста в большинстве
контрольных точек меньше всего у протокола PCoIP. Это даёт основание
говорить о его большей производительности для выбранного EXCELсценария. Это обусловлено, в первую очередь, более эффективным
использованием пропускной способности сети. При этом объём
передаваемых данных для PCoIP получается меньше за счёт эффективного
4
сжатия потока, причем это сжатие сбалансировано по входящему и
исходящему направлениям.
Исходя из структуры обобщенного критерия, производительность
виртуального рабочего места может быть определена из выражения
P
VDtest

S
t
общ

S
(1)
n
k t
i 1
i
i
где S – размер исходной матрицы, байт, ki – весовой коэффициент iой компонента структуры обобщённого критерия. Для различных
сценариев, реализуемых клиентами, весовые коэффициенты могут, вообще
говоря, различаться. В рамках данной работы не было возможности
определить указанные коэффициенты.
ЗАКЛЮЧЕНИЕ
Время
отработки
основных
циклов
преобразования
и
производительность на стороне сервера для всех протоколов примерно
одинаково. Различие в производительности протоколов проявляется, в
первую очередь, при загрузке результирующего потока данных на тонкий
клиент. А это немаловажно для облачных вычислений. При этом
эффективнее всего нагружает CPU (97…99%) при меньшей загрузке RAM
протокол PCoIP. Протоколы семейства RDP обнаруживают существенные
недостатки. Во-первых, это значительное отставание по обобщенному
критерию и другим параметрам производительности на тяжелых режимах
тестирования. Во-вторых, скачкообразная загрузка CPU, что является
причиной всего лишь половинной загрузки процессоров. В-третьих,
невозможность напрямую передать в виртуальную машину локальные
устройства, такие как USB Flash, принтеры, сканеры, веб-камеры. А все
эти ограничения существенны для конечных пользователей.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1.
Peter Mell, Timothy Grance, The NIST Definition of Cloud
Computing,
2011,
http://docs.ismgcorp.com/files/external/Draft-SP-800145_cloud-definition.pdf
2.
A. Berryman, P. Calyam, A. Lai, and M. Honigford. VDBench: A
Benchmarking Toolkit for Thin-client based Virtual Desktop Environments., In
Proc. of IEEE CloudCom, 2010
3.
Ватолин Д.С. Алгоритмы сжатия изображений. М.: МГУ, 1999.
76 с.
5