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的高性能是个什么球？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。