云计算环境下实时流媒体业务的性能研究

李汉雄，白光伟，＋，沈 航，承 骁

（1.南京工业大学 计算机科学与技术系，江苏 南京211816；2.南京理工大学 高维信息智能感知与系统教育部重点实验室，江苏 南京210094）

0 引 言

将现有的本地服务迁移至云中，或者重新开发一个完全基于云的流媒体服务都会遇到一系列在传统物理集群环境中从没遇过的技术性挑战［1］。在众多有关云计算的研究热点中，作为云计算支撑技术的虚拟化技术正在受到越来越多人的关注。

本文通过对部署在虚拟化环境中的流媒体系统的一系列的性能分析，通过实验模拟流媒体系统中一些基本操作以及播放视频的过程，研究在虚拟化环境中的用户体验和视频质量。实验结果表明，在迁移到云中后，没有经过任何优化的流媒体业务受资源隔离和共存虚拟机的影响较大。

1 相关工作

本节分析综述虚拟化技术领域的相关工作。随着近些年云计算的慢慢被人们熟悉，作为其中最重要的技术支撑虚拟化也有不少研究成果。

惠普实验室Padala Pradeep 等在不同配置的Xen 和OpenVZ环境下，通过实验分析了虚拟化对服务器整合的性能的影响［2］。2010年，Wang Guohui等深入研究了Amazon EC2数据中心的网络性能［3］。作者测量了在Amazon EC2虚拟机中处理器共享率、数据包时延、TCP/UDP 吞吐量、数据包丢失率。通过这些数据，作者发现即使数据中心利用率不高，虚拟化还是会显著的干扰到网络的吞吐量，使得吞吐量变得极不稳定，同时也会使得数据包的时延偏差变得不正常。文献 ［4］则关注了高性能科学计算类型的应用在Amazon EC2中性能表现。文献 ［5］的作者通过物理机上的客户端向运行在虚拟化环境下的HTTP服务器发送请求，对Xen虚拟化环境下的不同的网络应用共存时的网络吞吐性能做了一定的研究。而在虚拟化与具体应用方面，近年来的研究也不少。文献 ［6］中，Ishii，Masakuni等通过一个Hadoop模型来测试集群中VM 的特性和位置对于系统性能的影响程度。文献 ［7］则在他们对网络游戏的虚拟化技术研究中提出了一种新的混合资源调配模型，该模型使用更小更便宜的专有数据中心，同时在繁忙时间会服役虚拟化的云计算资源。文献 ［8］则通过一系列的实验表明现有的虚拟化环境中资源隔离机制对于私有的数据中心的影响。文献 ［9］揭示了基于Xen的虚拟化平台对诸如在线游戏与多媒体等时延敏感的应用的影响。但是文章对于流媒体与虚拟化的结合的研究并不充分，考虑的是特定场景，不具有普遍性。

针对上述问题，本文以虚拟化环境中的流媒体服务为对象，从用户的角度出发，分析在引入虚拟化环境后，播放视频前和播放视频时的用户体验会受到多大的影响。我们的实验全部是在自己搭建的私有云中完成，相对于使用Amazon EC2作为实验环境的研究和使用CloudSim 等模拟软件的研究来说，所有的实验环境都是可见的，而实验中的所有参数也是可以由我们自己决定的，因此我们的研究成果更有参考价值。

2 Xen虚拟机监视器

本文选择Xen来搭建我们的虚拟化平台。Xen是剑桥大学设计开发的一个开源的虚拟机监视器［10］，它允许在一台机器 （或主机）上运行并行操作系统的多个实例，或甚至不同的操作系统。它在多种不同的商业和开源应用程序中作为基础应用被广泛使用，如服务器虚拟化，基础设施即服务 （IaaS），桌面虚拟化，安全应用，嵌入式和硬件设备。Xen的架构如图1所示。

（1）Xen Hypervisor：整个Xen管理程序格外精简 （少于150 000行），它直接运行在硬件之上，负责管理CPU，内存和I/O 中断。

（2）Guest Domains：是虚拟环境，每一个都运行着自己的操作系统和应用程序。Guest VMs与硬件是完全分离的，也就是说它们没有权限来访问硬件或者调用I/O 功能。所以它们也通常被称为DomU。

（3）控制域 （Dom0）：是一个特殊的虚拟机，它有着特别的权限来直接访问硬件，处理所有对该系统I/O 的请求，并与其它虚拟机进行交互。

（4）Toolstack：Dom0 都包 含control stack （也称 为Toolstack），通过它用户可以直接创建、销毁和配置虚拟机。Toolstack的本质其实是暴露一个接口，这个接口既可以被命令行终端，也可以被图形化软件，甚至可以被云业务管理平台 （类似OpenStack或者CloudStack）来访问。

图1 Xen架构

本文选择Xen来搭建我们的虚拟化平台的原因，除了本身架构带来的优势外，Xen还支持全虚拟化技术。通过全虚拟化技术，我们可以在Xen虚拟机中运行任何未经修改的操作系统。通过这一特性，Xen中的虚拟机都可以获得可观的性能提升。

3 性能实验设计及环境

3.1 实验设计

用户在使用一个流媒体系统时，最开始的操作不外乎登录和注册、搜索感兴趣的视频、获取直播节目单等，系统的响应速度会严重影响用户体验。为了提升用户体验，同时减轻后端服务器的压力，可以利用现有的技术将这些实时操作背后的动态请求变为读取静态文件，诸如json和xml等。而json和xml本质上只是一种特殊的文本，它们文件体积都很小，因此与服务器通信交互的过程实际可以简单看成用户在请求服务器上的小文件。

在用户完成诸如登陆，搜索等操作后，就要开始观看他们所需的视频。对于用户来说，同一时刻他们只能观看一个视频，对于服务器来说，服务模式可以分为两种场景：微观上，一个视频在某个时刻是被很多用户同时观看的，例如观看热门视频或者直播；宏观上，所有的用户又分散着观看不同的视频。

在虚拟化的云环境中，一台物理机上不可能只运行一台虚拟机［11］，由共存虚拟机带来的资源隔离对于服务质量的影响一直是学术界和商业公司最为关注的研究热点。因此我们以用户开始播放为界，设计了两组实验，测试共存虚拟机对于云环境中流媒体服务的质量的影响。

在第一组实验中，我们并发请求虚拟化环境中Web服务器上的一个HTML页面，来模拟用户播放前的操作，同时增加空闲的共存虚拟机数量，测试共存虚拟机对小文件的并发访问性能会造成多大的影响。

在第二组实验中我们根据流媒体服务器的服务模式细分成两个实验：①第一个实验我们用脚本生成并发请求来播放服务器上的同一个视频来模拟第一个场景。②第二个实验我们用脚本生成不同视频点播请求来模拟第二个场景。

在第二组实验中将流媒体服务与不同类型业务组合，不同的业务对应着不同的磁盘负载类型，有的重读取，有的重写入。通过这些组合，本文试图找出对流媒体服务性能影响最大的业务类型。实验结果对于云环境中流媒体系统不同类型的业务组合的效率优化有着非常积极的指导意义。

3.2 硬件环境

全部的实验都是在两台Dell OptiPlex 3020上完成，一台模拟服务器，另一台模拟客户端产生服务请求。两台机器的配置完全一致，由于要部署Xen，因此我们选择了Ubuntu 12.04LTS作为操作系统。

由于要进行虚拟化操作，我们将机器BIOS 中的Intel虚拟化加速选项激活，使实验环境更接近真实的商业应用环境。每个虚拟机实例都采用相同的配置，1VCPU，1024MB的内存，20GB的磁盘空间。每个虚拟机实例也都安装了Ubuntu 12.04操作系统。客户机的配置情况与服务器基本一致。而在网络环境方面，为了排除其它干扰，我们将这两台实验机器连接在一台独立的100Mbps 交换机上。

3.3 软件环境

实验一中，我们在服务器上部署了Nginx （版本号为1.4.7）作为Web服务器响应客户端发来的并发访问请求，在客户端上我们使用了并发测试工具ab来产生并发请求，同时生成测试结果报告。

实验二 中，我 们 使 用DSS （Darwin streaming server）作为流媒体服务器，在客户端上所有的视频请求都是通过openRTSP发出。我们修改了openRTSP的源码，使得原本自带的QoS输出报告结果更为详细。同时，我们还自己编写了openRTSP的并发脚本，使得实验步骤简单化。

另外，我们使用Filebench在共存虚拟机上产生各种类型的磁盘负载实验中，我们使用了3种Filebench自带的负载模式：

（1）文件服务器：模拟的简单的文件服务器上的I/O操作。执行了一系列操作，包括创建、删除、附加、读取、写入和对文件目录树上的属性修改。默认有50个线程。

（2）数据库服务器：模拟数据库的操作。以Oracle 9i I/O 为模型对系统进行文件操作，主要是测试随机读取和写入性能。默认有200个读取进程、10个同步写进程以及1个日志进程。

（3）Web服务器：模拟简单的Web服务器上的I/O 操作。对一个目录树下的多个文件会进行打开－读取－关闭，这一整套操作，同时也会记录日志。默认有100个线程。

3.4 性能指标

在进行具体实验之前，我们再来介绍下实验结果中我们主要关注的几个性能指标：

（1）丢包率：丢包对于流媒体服务来说会造成很直观的影响，要么画面质量下降，甚至出现 “花屏”，要么丢帧，造成画面不连续。

（2）包间隔：根据RTP标准，包间隔指的是流文件里连续两个数据包的到达时间差。如果包间隔太大会造成视频播放的中断，影响用户体验。

（3）抖动：根据RTP标准文档，抖动指的是数据包接收者相对发送者的时间间隔差值的平均偏差。它一流文件的时间戳为单位。

尽管openRTSP自带的QoS报告已经比较详细，但我们还是通过修改源代码，增加了抖动的数据，同时为了方便评估和分析实验数据，我们还增加了代码使得QoS报告能够输出为文件。

4 实验结果及性能分析

4.1 实验一：空闲虚拟机对流媒体服务器的性能影响

我们首先启动第一台虚拟服务器 （Dom－1），Dom－1上部属了Nginx来响应客户端的服务请求，在客户机上则使用性能测试工具ab来产生并发请求，向服务器发送1000个并发请求，这1000个请求同时指向Nginx服务器上一个1kB的页面，测试并发的请求完成情况，结果将作为后续实验的基准对比数据。在得出基准数据后，我们改变空闲虚拟机的数量，进行相同的实验。实验结果见表1。

表1 1kB文件的访问数据

由表1可知，在基准测试中，完成全部连接请求总耗时226ms，最短请求处理时间为5ms。最大连接数为911，即当并发连接数超过911后，服务器开始出现瓶颈，服务器完成请求时间从15ms跃升为219ms。

在增加了一台空闲的虚拟机后，完成全部连接请求总耗时237ms，比基准数据长了4.8%。最短请求处理时间为8ms，比基准数据慢了60%。服务器在并发连接数达到898后就遇到了瓶颈，服务器的并发能力下降了1.4%。

在空闲虚拟机数量增加为两台后，完成全部连接请求总耗时245ms，比基准数据长了8.4%。最短请求处理时间达到了10ms，是基准数据的2倍。服务器在并发连接数达到859后遇到了瓶颈，并发能力相对基准数据下降了5.7%。

由这3个实验的结果可以得出，在只有两台空闲虚拟机的情况下，服务器的性能已经有了较为严重的下降，而在实际的商业环境中，一台物理机上运行的虚拟机数量可能有40甚至60台，可以预见，当空闲虚拟机的数量不断增加时，实验中的Web服务器的并发性能还会有着更为明显的下降。而并发性能的下降意味着如果有大量用户进行播放前操作 （登录、注册、搜索等）时，他们的服务质量会受到损害。而在用户的惯性思维中，流媒体系统中最容易发生延时和卡顿的阶段是在观看视频时。如果登录、搜索、更新等这些操作都有较长的时延，那么用户对于这个系统的认可度就会急剧降低，甚至放弃继续使用。

为了对比小文件和大文件的访问性能，我们增加了两组访问10kB 和20kB 文件的实验，由实验数据表2、表3可以得出，无论增加了几台空闲虚拟机，文件的并发访问数据并没有什么明显的改变。因此，我们认为在虚拟化环境中，小文件的并发性能更容易受到空闲虚拟机的影响，而较大的文件则没有什么影响。

在前面的实验中，为了模拟真实环境，我们让增加的空闲虚拟机分配在与Dom－1同一个物理核心上，在接下来的试验中，我们通过命令将虚拟机分配到不同的物理核心上，然后重复之前实验步骤，再次比较并发访问文件的性能。表4是分配不同物理核心后的实验数据。

将虚拟机分配不同的CPU 核心后，由表4 可以发现，即使增加了共存虚拟机的数量，流媒体服务器上小文件的并发访问性能也没有明显的下降，甚至可以认为完全没有影响。

本节的实验中我们探究了空闲虚拟机对流媒体系统的影响，从实验结果可以得出当一颗物理核心上运行多个共存虚拟机时，即使这些共存的虚拟机上没有任何负载，对于流媒体系统也会产生影响，当这些虚拟机运行在不同的CPU 物理核心上时，流媒体服务器就几乎没有任何的性能下降。而在虚拟化的云环境中，CPU 和内存这两种资源是通过分割从而分配给多个虚拟机，共存虚拟机对于流媒体服务器的影响，本质上来说就是由于CPU 共享造成的。在有多个虚拟机后，CPU 的调度队列里不再只有流媒体服务器的CPU 请求，还包含了其它共存虚拟机的一些请求，因此在小文件并发访问这一依赖CPU 的性能测试中，我们观测到了较为明显的性能下降。所以为了提高云环境中流媒体服务的性能，我们应当尽可能将文件静态化，缓存化，从流媒体服务器上分离出来，从而减轻流媒体服务器的压力，提高响应速度，提升用户体验。

表2 10kB文件的访问数据

表3 20kB文件的访问数据

表4 分配不同物理核心后的小文件访问数据

4.2 实验二：磁盘负载对流媒体服务的性能影响

4.2.1 场景一：单一视频并发访问

在场景一中，所有并发请求都指向同一个视频文件。我们选取的测试视频长度为60s，大小为32.9MB，视频与音频的一些参数见表5。

表5 视频文件基本参数

通过修改并发脚本中的并发数，我们观察到，针对选定视频，当同时观看同一个视频的用户数为12时，这12个用户享受的视频服务质量没有任何的损失。实验数据见表6，这一组数据也会作为后续操作的基准数据进行参考比较。

表6 基准数据

由于实验环境为内网，所以整个流媒体文件的抖动非常小，包间隔的平均值也比较小，视频流的平均包间隔约为2.37ms，最大间隔也就在101ms左右。而由于音频流的文件体积相对视频流来说要小很多，所以包间隔要比视频流来的大。

在得到基准数据后，我们使用Filebench在共存的虚拟机加上不同类型的负载，再进行相同的实验。我们用一台虚拟机作为流媒体服务器，另一台虚拟机作为 “干扰”服务器，将这两台虚拟机分配到了不同的物理核心上，这样可以避免实验结果受CPU 干扰，从而让干扰因素只剩下磁盘。实验结果如表7、表8和图2所示。数据中的Base表示基准数据组，而File、Oltp和Web分别对应我们在Filebench中选择的负载模式。从实验数据中可以看出，在用户都访问单一视频时，与流媒体共存的虚拟机加上负载后，在3组负载中，Oltp模式也就是数据库服务器对流媒体服务器的影响最大，视频包间隔比基准数据大了48.7%，音频包间隔比基准数据大了10%，根据计算，视频抖动比基准数据大了8.3%，音频抖动比基准数据大了12.2%。而File和Web模式则对流媒体系统的影响较小，没有Oltp明显。因此为了提高整体系统的性能，在部署流媒体云服务时应该考虑将尽可能多的数据做成缓存，而不是直接访问后台数据库，这样能提高用户的访问和响应速度，减少数据库服务器对流媒体服务器的干扰。

表7 场景一下视频的包间隔/ms

表8 场景一下音频的包间隔/ms

图2 场景一下音视频流的抖动

4.2.2 场景二：多个视频同时访问

在场景二中，为了模拟流媒体系统中另一个常见的流量模型，即没有某个视频被大量用户同时访问，我们修改了测试脚本，请求不同的视频。经过不断增加用户数量，最终得到当为21个用户时，整个系统的服务质量没有任何损耗，客户端上也观察不到丢包。通过统计，这21个视频总大小为611.4MB，长度都为60s。而由于这些视频都是动态码率，因此不会像第一组实验遇到高码率的画面叠加造成的网络带宽高峰，所以支持的并发数量比实验一要大。

在场景二中继续重复场景一中的步骤，通过Filebench来给与流媒体服务器共存的虚拟机上添加不同的磁盘负载模式，比较在场景二中，用户接收到的视频服务质量会有什么样的影响。

实验数据，如图3，图4 和表9 所示，数据中的Base组表示基准数据即没有任何负载。由数据可以看出，对流媒体服务器来说，File模式对流媒体服务器的性能造成了非常严重的影响，平均包间隔指标中，最严重的接近3倍，而在最大包间隔指标中，File的数据甚至比基准数据差了70多倍。包间隔变大意味着客户端收到连续两个数据包时间变长，视频卡顿甚至丢包的可能性也就变大，最终都会影响客户端的视频质量和用户体验。

而Oltp和Web模式对平均包间隔影响很小，但对最大包间隔指标有比较明显的影响，对于整个视频来说，可以认为大部分的视频包都能稳定得连续达到，但会存在一小部分数据包间隔较长的时间才能达到，结果就是用户观看的视频产生画面卡顿、清晰度下降，音质变差。

图3 视频流的平均包间隔

图4 音频流的平均包间隔

表9 视频流与音频流的最大包间隔/ms

在抖动指标中，如图5、图6所示，影响最大的依然是File模式，相对较小的是Web模式。在绝大部分的视频测试结果中，加上负载后抖动都成倍的增加了，这仅仅是在内网没有其它网络干扰的情况下的数据。如果一个商业的流媒体云服务上线开始服务后，可想而知在实际网络环境中的抖动会加剧到什么程度。而比较Oltp与Web模式对抖动影响可以看出，Oltp对流媒体服务器的影响更大，再次验证了我们在实验一的建议，通过缓存可以提高流媒体云服务的整体性能。

图5 视频流的抖动

图6 音频流的抖动

在分析完了包间隔和抖动后，我们来看一下另一个性能指标，丢包率，这里我们通过接收到包数量来表示，实验数据如图7、图8所示。通过实验结果可以得出，无论是视频流还是音频流，File模式对于流媒体服务的影响最大，丢包非常严重，最严重的一组接收到的数据包连一半都不到，肯定无法满足观看视频的基本要求。而对于Oltp 与Web来说，丢包率非常小，结合包间隔和抖动后，这两个模式虽然几乎收到全部的数据包，但是它们到达的时间差比较大，可以认为用户在客户端上可以接收到全部的视频和音频文件，但是会出现卡顿的情况，视频质量和用户体验还是有着不小的损失。

图7 视频流接收到包数量

图8 音频流接收到包数量

在完成实验二中的所有实验后，我们发现当流媒体服务器与其它服务器共存时，这些共存服务器上如果存在着重磁盘操作的应用时，流媒体服务器的性能肯定会受到影响。场景二中的视频质量和用户体验受到的性能损失相比较场景一更加明显。这是因为，流媒体服务器中包含了大量网络传输操作，因而Dom0会产生中断来发送流媒体服务器中的数据包，而当共存的虚拟机进行磁盘操作时，由于磁盘在虚拟机之间是共享的，不是分割的，所有的虚拟机中的磁盘中断都由Dom0来管理，而磁盘中断的优先级比网络中断的优先级要高，并且它们的数量要远多于流媒体服务器中的网络中断数量，因此Dom0 会优先响应那些磁盘中断，从而使得流媒体服务器得不到充分的响应。

5 结束语

本文针对一个部署在云环境下的流媒体系统进行了性能分析。首先通过访问小文件来模拟用户与服务器通信时传输json和xml文件的情形，分析了空闲的共存虚拟机对于流媒体服务器向用户提供播放前服务时性能的影响。通过实验发现即使没有任何负载，共存的虚拟机在没有进行CPU 隔离的情况下依然会对流媒体服务器产生一定的性能影响。

通过编写并发脚本，同时搭配不同的磁盘负载模式，来模拟流媒体服务器在响应用户观看过程中最常见的两种场景，分析流媒体服务器与这些应用共存时性能降低程度。实验结果表明，在场景一中，用户同时观看同一个视频时，共存虚拟机上的磁盘负载对于流媒体服务器影响比较小。但在比较3个负载模型的结果后，还是可以发现较为明显的是数据库服务器，因此减少对于后端数据库的访问可以提高流媒体服务器的性能。在场景二中，用户分散观看不同视频时，共存虚拟机对于流媒体服务器的影响就要大的多，其中File模式的影响最大，这是由于File模式对于磁盘操作最为频繁，造成大量的I/O 中断，这些中断的优先级是高于流媒体服务器中的网络传输中断，因此流媒体服务器在场景二中受到的影响更大，甚至不能正常工作。

我们的工作可以作为研究云计算环境与流媒体服务器性能的一个重要基础，为考虑将流媒体服务与云融合的研究者提供性能优化方面的参考。

［1］Cheng Luwei，Wang Cho－Li.Network performance isolation for latency－sensitive cloud applications［J］.Future Generation Computer Systems，2013，29 （4）：1073－1084.

［2］Padala Pradeep.Performance evaluation of virtualization technologies for server consolidation［R］.HP Labs Tec Report，2007.

［3］Wang Guohui，TS Eugene Ng.The impact of virtualization on network performance of Amazon EC2data centerm ［C］//Proceedings of IEEE INFOCOM，2010：1－9.

［4］Walker E.Benchmarking Amazon EC2for high－performance scientific computing［J］.Usenix Login，2008，33 （5）：18－23.

［5］Mei Y，Liu L，Pu X，et al.Performance measurements and analysis of network i/o applications in virtualized cloud ［C］//Proceedings of IEEE International Conference on Cloud Computing，2010：59－66.

［6］Ishii Masakuni，Han Jungkyu，Makino Hiroyuki.Design and performance evaluation for hadoop clusters on virtualized environment［C］//Proceedings of IEEE International Conference on Information Networking，2013：244－249.

［7］Nae Vlad.The impact of virtualization on the performance of massively multiplayer online games ［C］//Proceedings of the 8th Annual Workshop on Network and Systems Support for Games，2009：9－14.

［8］Somani G，Chaudhary S.Application performance isolation in virtualization ［C］//Proceedings of the IEEE International Conference on Cloud Computing，2009：41－48.

［9］Barker Sean Kenneth，Prashant Shenoy.Empirical evaluation of latency－sensitive application performance in the cloud ［C］//Proceedings of the First Annual ACM SIGMM Conference on Multimedia Systems.ACM，2010：35－46.

［10］Chisnall D.The definitive guide to the xen hypervisor［M］.Pearson Education，2008：16.

［11］Ben P，Justin P，Teemu K，et al.Extending networking into the virtualization layer［C］//Proceedings of the 8th ACM Workshop on Hot Topics in Networks（HotNets－VIII），2009.