比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

比nginx-rtmp高三倍性能的SRS的高性能是个什么球？相关推荐

Nginx突破高并发的性能优化 - 运维笔记
在日常的运维工作中,经常会用到nginx服务,也时常会碰到nginx因高并发导致的性能瓶颈问题.今天这里简单梳理下nginx性能优化的配置(仅仅依据本人的实战经验而述,如有不妥,敬请指出~) 一.这里 ...
nginx rtmp 编码_基于Nginx的媒体服务器技术
国内应用比较多的开源流媒体服务器nginx-rtmp-module一直存在功能少.集群化难度大等问题.在LiveVideoStack线上分享中,PingOS 开源项目组开发工程师.UCloud RTC ...
如何让你的Nginx 提升10倍性能？
来源:www.zcfy.cc/article/10-tips-for-10x-application-performance-nginx-22.html 原文:https://www.nginx.co ...
MurmurHash算法：高运算性能，低碰撞率的hash算法
MurmurHash算法:高运算性能,低碰撞率,由Austin Appleby创建于2008年,现已应用到Hadoop.libstdc++.nginx.libmemcached等开源系统.2011年A ...
Mac使用nginx+rtmp服务器
一.安装Homebrow 已经安装了brow的可以直接跳过这一步. 执行命令 ruby -e "$(curl -fsSL https://raw.githubusercontent.com/ ...
Nginx RTMP 功能研究
Nginx-RTMP功能调研 1. RTMP协议介绍...2 2.RTMP server.3 2.1当前的流媒体server.3 2.2Wowza功能...3 3.Nginx-based RTMP s ...
nginx与apache详细性能对比
之前一直研究nginx的源代码,最近有时间也做了下nginx与apache的性能对比,希望能够够对大家有所帮助! 转载请注明:http://blog.csdn.net/lengzijian/artic ...
服务器搭建和使用 ubuntu_Ubuntu中使用Nginx+rtmp搭建流媒体直播服务
一.背景本篇文章是继上一篇文章<Ubuntu中使用Nginx+rtmp模块搭建流媒体视频点播服务>文章而写,在上一篇文章中我们搭建了一个点播服务器,在此基础上我们再搭建一个直播服务器, ...
armlinux 搭建nginx + rtmp服务器
1 综合篇点我 2 uboot移植点我 3 uboot lcd驱动点我 4 kernel移植点我 5 kernel lcd驱动点我 6 摄像头驱动点我 7 ubuntu base移植点我 ...

比nginx-rtmp高三倍性能的SRS的高性能是个什么球？

比nginx-rtmp高三倍性能的SRS的高性能是个什么球？相关推荐

最新文章

热门文章