Media Center
比nginx-rtmp高三倍性能的SRS的高性能是个什么球?
SRS(Simple Rtmp Server)单进程能支持9000并发,nginx-rtmp单进程最多支持3000个,单进程的性能SRS(Simple Rtmp Server)是nginx-rtmp的三倍。SRS(Simple Rtmp Server)单进程性能如何做到nginx-rtmp的三倍的?SRS(Simple Rtmp Server)哪几个结构极大提升了性能? 先来看看我们遇到的问题,RTMP协议和HTTP协议是又很大不同的。nginx在分发HLS,即m3u8文本文件和ts视频文件时,对所有连接发送的都是同一个内容,甚至可以调用sendfile让内核自己发fd去,nginx服务器自己要干的事情很少了;如果nginx必须把每个ts的内容读出来,修改里面某些字节,然后每个客户端一次发送的数据前还得加点什么,nginx就会很忙了。 这就是RTMP,每个video或audio包,在发送给某个连接之前,都得修改下时间戳(至少FMS是每个连接收到的媒体数据都是从0开始的时间戳),然后把包再拆分成一些小片段(chunked),每个chunk包前面加几个字节的头信息,然后发送。我勒个去~ 举个例子,假设有个视频的I帧有200000bytes,默认的chunk包最大是128字节,所以得拆分成200000/128=1562个chunk包来发送,每个chunk包前面都要加chunk头。没有办法sendfile了吧?可以想象得到内存要被蹂躏成什么样子吧?这就是RTMP流媒体服务器麻烦的地方了,客官可以自己想下搞个什么样子的算法能最高效发送粗去~ nginx-rtmp是性能最高的服务器,比crtmpd都要高,red5根本就低两个级别,wowza也没有它高。SRS(Simple Rtmp Sever)做了什么能够比nginx-rtmp单进程还要高三倍? 第一点,st-load,这个是SRS(Simple Rtmp Sever)能做到高性能的最重要的原因,一个st-load可以模拟2000+的客户端。一个牛逼的benchmark的工具;如果没有st-load,如何知道系统的性能瓶颈在哪里?总不能打开3000个flash页面播放rtmp流吧?开启3000个ffmpeg来抓流?不靠谱。这就是高性能第一定律:高性能不是想象和猜测粗来的,而是测试、调试和改进粗来的。 第二点,gperf/gprof性能benchmark功能。在编译SRS(Simple Rtmp Sever)时,就可以打开gcp或者gprof的性能分析选项,灰常方便就可以拿到数据。缩短了改进和优化的开发周期。 第三点,引用计数的msgs避免内存拷贝。从编码器收到的video/audio数据,转换成SrsSharedPtrMessage放到每个连接的发送队列,避免每个都拷贝一次;因为发送给每个客户端的消息(不是chunked包)头可能不一样,譬如时间戳不一样,但是消息的payload是一样的。 第四点,使用writev发送chunked包,避免消息到chunked包的内存拷贝。可以开辟一个header的缓冲区,专门放每个chunked包的header,然后用iovc保存头的指针和大小,payload的指针和大小,用writev就可以一次发送。 第五点,mw(merged-write)技术,即一次发送多个消息。虽然每个消息使用writev可以避免拷贝,还有更高效的是一次发送多个消息,即把多个消息的chunked头写在header的缓冲区,iovc保存多个消息的chunked头和payload指针,一次writev发送多个消息。这个是最关键所在。 第六点,减少timeout recv,每个连接都是一个st-thread在服务。在发送之前,线程得尝试从连接收取消息,譬如客户端的stop之类的;所以只能recv时指定timeout,譬如300毫秒如果还没有收到消息,就发送连接队列中的消息。这个会导致st的timeout红黑树操作频繁。实际上,可以直接开启一个recv线程,因为客户端的消息非常少,避免timeout接收。 第七点,fast buffer和cache。譬如每次取消息的数组,使用cache;使用fast buffer避免频繁删除;使用header的cache。 第八点,vector还是list?有的地方看起来list更高效,譬如simple buffer这种频繁删除头,以及在结尾加入数据,看起来是list应该做的事情。但是实际上测试发现,vector比list高10%性能。所以,回到第一点,高性能不是猜测和想象粗来的;有的时候有些代码写得很慢,但是这个频率非常低,那么就不要考虑性能,而要考虑可读性。我觉得可以算是高性能第二定律:不要总是考虑高性能,可读性更重要。 另外,nginx-rtmp有多进程啦。没错,可惜SRS(Simple Rtmp Sever)也可以有多进程啦;可以有为何没有做呢?首先,9000个连接还不够么?1Mbps的码率可以到9Gbps了哦,伦家的机房交换机有那么牛逼么?敢一个服务器服务那么多用户么?其次,多进程不是万金油的,不过是一种技术,不是没有多进程就低人一等,有了多进程就高人一等,别那么技术控,关键在于对于客户有啥价值。再次,可以用RTMP302支持多进程,这个是最稳定的多进程技术。最后,杰哥的BLS已经实现了多进程,他设计的多进程架构,即一个源站fork多个边缘的进程的结构,是最简单的多进程通信模型。这可以引申出高性能第三定律:表当真呢,高性能不是万金油。 SRS(Simple Rtmp Server)的性能测试,请参考: https://github.com/winlinvip/simple-rtmp-server/wiki/v1_CN_Performance SRS(Simple Rtmp Server)的性能优化commit,请参考: https://github.com/winlinvip/simple-rtmp-server/tree/2.0release#performance
北京观止创想科技有限公司
TEL: 010-8233 1879 FAX: 010-8233 1989
EMAIL: chnvideo@chnvideo.com ADD: 北京市海淀区知春路1号学院国际大厦801
Copyright © 2014 BRAVO观止创想,保留所有权利 京ICP备12047633号