SRS(Simple Rtmp Server)單進程能支持9000并發(fā)，nginx-rtmp單進程最多支持3000個，單進程的性能SRS(Simple Rtmp Server)是nginx-rtmp的三倍。SRS(Simple Rtmp Server)單進程性能如何做到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服務器自己要干的事情很少了;如果nginx必須把每個ts的內(nèi)容讀出來，修改里面某些字節(jié)，然后每個客戶端一次發(fā)送的數(shù)據(jù)前還得加點什么，nginx就會很忙了。

這就是RTMP，每個video或audio包，在發(fā)送給某個連接之前，都得修改下時間戳(至少FMS是每個連接收到的媒體數(shù)據(jù)都是從0開始的時間戳)，然后把包再拆分成一些小片段(chunked)，每個chunk包前面加幾個字節(jié)的頭信息，然后發(fā)送。

舉個例子，假設有個視頻的I幀有200000bytes，默認的chunk包最大是128字節(jié)，所以得拆分成200000/128=1562個chunk包來發(fā)送，每個chunk包前面都要加chunk頭。沒有辦法sendfile了吧?可以想象得到內(nèi)存要被蹂躪成什么樣子吧?這就是RTMP流媒體服務器麻煩的地方了，客官可以自己想下搞個什么樣子的算法能最高效發(fā)送粗去~

nginx-rtmp是性能最高的服務器，比crtmpd都要高，red5根本就低兩個級別，wowza也沒有它高。SRS(Simple Rtmp Sever)做了什么能夠比nginx-rtmp單進程還要高三倍?

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

第二點，gperf/gprof性能benchmark功能。在編譯SRS(Simple Rtmp Sever)時，就可以打開gcp或者gprof的性能分析選項，灰常方便就可以拿到數(shù)據(jù)?？s短了改進和優(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)技術，即一次發(fā)送多個消息。雖然每個消息使用writev可以避免拷貝，還有更高效的是一次發(fā)送多個消息，即把多個消息的chunked頭寫在header的緩沖區(qū)，iovc保存多個消息的chunked頭和payload指針，一次writev發(fā)送多個消息。這個是最關鍵所在。

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

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

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

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