基于Red 5的桌面共享系统的性能优化-综述篇

项目总体介绍

Red5作为著名的Open Source  的Flash Media Server，自推出以来，收到广大的开发者的关注，但是在它基础上构建成功的项目比较少见，是Red 5本身的问题，还是Adobe指定的规范的问题，如果对此类系统进行优化是一个我们想做商业级产品应用需要考虑的问题。

 

基于Red5的桌面共享系统是部门新开的一个项目，目前完成了一些基本的功能，如桌面共享，远程控制等。

可以由下图说明一下整个项目简单的业务逻辑：

 

 1） C++ Client负责把本地的桌面抓成图片（例如300 ms抓一次屏幕），如果是第一屏，则是关键帧，抓出的格式是BMP，并使用ZLib进行压缩，如果是第二屏，则跟第一屏的数据进行对比，最终的数据只是变化的部分。

 

注： 并不是我们不想把无损的BMP传给Red 5，可恨的是，Adobe支持的编码就是这种称之为Screen Video Codec，它可以简单描述成BMP（变化部分）+ZLib

 

 2） C++Client端抓出的ZLib桌面抓屏图片数据，发送给Red 5，Red 5 收到桌面的图片（BMP）boardcast给其它的Flash client端。

 

2.提出问题

 

首先从理论上分析一下这个架构只要的问题在哪里，然后我们才可以有的放矢地进行优化：

1）带宽问题

举个例子说明：

第一帧数据为例：

当用户客户机PC的resolution是：1440*900，BMP抓屏后大约3.7MB（byte）

用ZLib压缩后，大约为400KB（byte）

 

第二帧数据（只是变化部分）：

用ZLib压缩后，大约为10KB（byte）

 

显然对于第一帧数据（关键帧），延时是非常严重的：400/48.25=8秒（上传给Red 5）+400/64=6.25 = 14.25秒

另外如果桌面变化特别快(如视频播放），也会造成很重的延时，当然可以接受的是，我们的应用场景应该不适合于这种屏幕变化特别大的情形，我们项目背景应该适合于做presentation等文档共享方面的场景。尽管可以从用户体验方面去提醒用户，但是从这里的数据可以看出，我们的瓶颈确实还是在带宽，还有Flash 的Codec实在是有点落后。

 

注：以网通1M带宽为例：

上行带宽：386Kb=48.25KB

下行带宽：512Kb=64KB

 

注：这篇blog，已经很长时间了，我们在这方面已经有了突破，我们找到了一个非产好的codec，实现了ZLib的高压缩，具体的技术涉及到公司的机密，不能透露望谅解，效果已经非常好了，一个3.7M的一帧数据，压缩后大概200KB了，这个Codec已经可以接受了。

 

2）单Red 5 服务器的架构问题

我们这样的系统，做集群是在所难免的，一方面可以让负载均衡，另外一方面提高系统的可用性，我会单独就这个方面谈谈我们系统的集群设计

 

3）Red 5本身是基于Java的技术,虚拟机停顿（Pause）会引起桌面抓屏数据的延时

Red5是纯Java的开源项目，Java语言的特性之一是通过JVM来管理内存的回收和创建，程序员不用管这些东西，从某种程度上减轻了程序员的工作量，但是同样也会带来问题：如果对于JVM的垃圾回收机制不了解，一旦出现问题，将无法入手。我们知道JVM把内存分配在Heap上，当对象不可到达时，该对象的内容，JVM通过扫描根集的方法，如果发现对象可到达，则做标记，不可到达，则将对象内存释放。注意，我们的JVM的GC Thread（Dameon）启动时，所有的应用程序的工作线程会停止（Pause），而对于我们系统而言，我们需要尽量小的Pause time，以保证最快的响应速度，保证语音和视频数据的实时性，特别是语音的实时性要求很高

 

注：对于Concurrent Mark Sweep垃圾回收器，应用程序线程和GC Thread是并发运行的，但是并不是完全并发的，在Initial Mark和remark阶段，应用程序线程会停顿。

 

4）VOIP的优化

VOIP确实是个很麻烦的问题，VOIP对于实时性要求特别高，上次看到一个标准，语音的延时最好不要超过250ms，这个是非常有挑战性的数字，我们在优化语音方面做了很多工作，例如拆分Video数据包，提高语音数据传输的优先级

 

从目前的结果来看，这四个问题是本次主题需要讨论的地方，下面将就这个方面分四篇文章分别来讲述。

 

 

 

评论

1 楼 takingoff 2010-12-05  

后面四篇 没有了？