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)真呢,高性能不是萬金油。?