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

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

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

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

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

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

第六點(diǎn)，減少timeout recv，每個(gè)連接都是一個(gè)st-thread在服務(wù)。在發(fā)送之前，線程得嘗試從連接收取消息，譬如客戶端的stop之類的；所以只能recv時(shí)指定timeout，譬如300毫秒如果還沒(méi)有收到消息，就發(fā)送連接隊(duì)列中的消息。這個(gè)會(huì)導(dǎo)致st的timeout紅黑樹操作頻繁。實(shí)際上，可以直接開(kāi)啟一個(gè)recv線程，因?yàn)榭蛻舳说南⒎浅Ｉ伲苊鈚imeout接收。

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

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

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