srs之与nginx-rtmp性能对比

最新推荐文章于 2025-02-05 16:35:25 发布

转载最新推荐文章于 2025-02-05 16:35:25 发布 · 1.9k 阅读

文章标签：

#性能 #rtmp #nginx

nginx-理解专栏收录该内容

27 篇文章

订阅专栏

本文探讨了SRS(SimpleRtmpServer)如何通过多种技术手段实现相较于nginx-rtmp单进程性能提升三倍的目标。从st-load工具的使用到gperf/gprof性能benchmark功能，再到避免内存拷贝的方法等，全面解析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