SRS和nginx-rtmp性能對比

SRS(Simple Rtmp Server)單進(jìn)程能支持9000并發(fā)，nginx-rtmp單進(jìn)程最多支持3000個，單進(jìn)程的性能SRS(Simple Rtmp Server)是nginx-rtmp的三倍。SRS(Simple Rtmp Server)單進(jìn)程性能如何做到nginx-rtmp的三倍的？SRS(Simple Rtmp Server)哪幾個結(jié)構(gòu)極大提升了性能？?
先來看看我們遇到的問題，RTMP協(xié)議和HTTP協(xié)議是又很大不同的。nginx在分發(fā)HLS，即m3u8文本文件和ts視頻文件時，對所有連接發(fā)送的都是同一個內(nèi)容，甚至可以調(diào)用sendfile讓內(nèi)核自己發(fā)fd去，nginx服務(wù)器自己要干的事情很少了；如果nginx必須把每個ts的內(nèi)容讀出來，修改里面某些字節(jié)，然后每個客戶端一次發(fā)送的數(shù)據(jù)前還得加點什么，nginx就會很忙了。?
這就是RTMP，每個video或audio包，在發(fā)送給某個連接之前，都得修改下時間戳(至少FMS是每個連接收到的媒體數(shù)據(jù)都是從0開始的時間戳)，然后把包再拆分成一些小片段(chunked)，每個chunk包前面加幾個字節(jié)的頭信息，然后發(fā)送。我勒個去~?
舉個例子，假設(shè)有個視頻的I幀有200000bytes，默認(rèn)的chunk包最大是128字節(jié)，所以得拆分成200000/128=1562個chunk包來發(fā)送，每個chunk包前面都要加chunk頭。沒有辦法sendfile了吧？可以想象得到內(nèi)存要被蹂躪成什么樣子吧？這就是RTMP流媒體服務(wù)器麻煩的地方了，客官可以自己想下搞個什么樣子的算法能最高效發(fā)送粗去~?
nginx-rtmp是性能最高的服務(wù)器，比crtmpd都要高，red5根本就低兩個級別，wowza也沒有它高。SRS(Simple Rtmp Sever)做了什么能夠比nginx-rtmp單進(jìn)程還要高三倍？

第一點，st-load，這個是SRS(Simple Rtmp Sever)能做到高性能的最重要的原因，一個st-load可以模擬2000+的客戶端。一個牛逼的benchmark的工具；如果沒有st-load，如何知道系統(tǒng)的性能瓶頸在哪里？總不能打開3000個flash頁面播放rtmp流吧？開啟3000個ffmpeg來抓流？不靠譜。這就是高性能第一定律：高性能不是想象和猜測粗來的，而是測試、調(diào)試和改進(jìn)粗來的。

第二點，gperf/gprof性能benchmark功能。在編譯SRS(Simple Rtmp Sever)時，就可以打開gcp或者gprof的性能分析選項，灰常方便就可以拿到數(shù)據(jù)?？s短了改進(jìn)和優(yōu)化的開發(fā)周期。

第三點，引用計數(shù)的msgs避免內(nèi)存拷貝。從編碼器收到的video/audio數(shù)據(jù)，轉(zhuǎn)換成SrsSharedPtrMessage放到每個連接的發(fā)送隊列，避免每個都拷貝一次；因為發(fā)送給每個客戶端的消息(不是chunked包)頭可能不一樣，譬如時間戳不一樣，但是消息的payload是一樣的。

第四點，使用writev發(fā)送chunked包，避免消息到chunked包的內(nèi)存拷貝?？梢蚤_辟一個header的緩沖區(qū)，專門放每個chunked包的header，然后用iovc保存頭的指針和大小，payload的指針和大小，用writev就可以一次發(fā)送。

第五點，mw(merged-write)技術(shù)，即一次發(fā)送多個消息。雖然每個消息使用writev可以避免拷貝，還有更高效的是一次發(fā)送多個消息，即把多個消息的chunked頭寫在header的緩沖區(qū)，iovc保存多個消息的chunked頭和payload指針，一次writev發(fā)送多個消息。這個是最關(guān)鍵所在。

第六點，減少timeout recv，每個連接都是一個st-thread在服務(wù)。在發(fā)送之前，線程得嘗試從連接收取消息，譬如客戶端的stop之類的；所以只能recv時指定timeout，譬如300毫秒如果還沒有收到消息，就發(fā)送連接隊列中的消息。這個會導(dǎo)致st的timeout紅黑樹操作頻繁。實際上，可以直接開啟一個recv線程，因為客戶端的消息非常少，避免timeout接收。

第七點，fast buffer和cache。譬如每次取消息的數(shù)組，使用cache；使用fast buffer避免頻繁刪除；使用header的cache。

第八點，vector還是list？有的地方看起來list更高效，譬如simple buffer這種頻繁刪除頭，以及在結(jié)尾加入數(shù)據(jù)，看起來是list應(yīng)該做的事情。但是實際上測試發(fā)現(xiàn)，vector比list高10%性能。所以，回到第一點，高性能不是猜測和想象粗來的；有的時候有些代碼寫得很慢，但是這個頻率非常低，那么就不要考慮性能，而要考慮可讀性。我覺得可以算是高性能第二定律：不要總是考慮高性能，可讀性更重要。

另外，nginx-rtmp有多進(jìn)程啦。沒錯，可惜SRS(Simple Rtmp Sever)也可以有多進(jìn)程啦；可以有為何沒有做呢？首先，9000個連接還不夠么？1Mbps的碼率可以到9Gbps了哦，倫家的機(jī)房交換機(jī)有那么牛逼么？敢一個服務(wù)器服務(wù)那么多用戶么？其次，多進(jìn)程不是萬金油的，不過是一種技術(shù)，不是沒有多進(jìn)程就低人一等，有了多進(jìn)程就高人一等，別那么技術(shù)控，關(guān)鍵在于對于客戶有啥價值。再次，可以用RTMP302支持多進(jìn)程，這個是最穩(wěn)定的多進(jìn)程技術(shù)。最后，杰哥的BLS已經(jīng)實現(xiàn)了多進(jìn)程，他設(shè)計的多進(jìn)程架構(gòu)，即一個源站fork多個邊緣的進(jìn)程的結(jié)構(gòu)，是最簡單的多進(jìn)程通信模型。這可以引申出高性能第三定律：表當(dāng)真呢，高性能不是萬金油。?