參考2:Storm DRPC 使用
參考3:Storm DRPC 使用及訪問(wèn)C++ Bolt問(wèn)題的解決方法
參考4:Storm 多語(yǔ)言支持之ShellBolt原理及改進(jìn)
參考6：Base64編碼及編碼性能測(cè)試 [改進(jìn)]
參考7：zlib使用與性能測(cè)試
參考8：十分簡(jiǎn)單的redis使用說(shuō)明及性能測(cè)試
[參考1]的結(jié)論與局限
參考種對(duì)
Storm性能進(jìn)行測(cè)試，得出了以下結(jié)論：
storm單條流水線的處理能力大約為20000 tupe/s, (每個(gè)tuple大小為1000字節(jié))
storm系統(tǒng)本省的處理延遲為毫秒級(jí)
在集群中橫向擴(kuò)展可以增加系統(tǒng)的處理能力，實(shí)測(cè)結(jié)果為1.6倍
Storm中大量的使用了線程，即使單條處理流水線的系統(tǒng)，也有十幾個(gè)線程在同時(shí)運(yùn)行，所以幾乎所有的16個(gè)CPU都在運(yùn)行狀態(tài)，load average 約為 3.5
Jvm GC一般情況下對(duì)系統(tǒng)性能影響有限，但是內(nèi)存緊張時(shí)，GC會(huì)成為系統(tǒng)性能的瓶頸
使用外部處理程序性能下降明顯，所以在高性能要求下，盡量使用storm內(nèi)建的處理模式
作者對(duì)strom的處理能力和可擴(kuò)展性進(jìn)行了測(cè)試，給出了很有說(shuō)服力的數(shù)據(jù)。但還不能滿(mǎn)足我們的需要：
1）由于作者使用的tuple為1000字節(jié)，也就是1K，數(shù)據(jù)量相對(duì)較小，而在實(shí)際使用過(guò)程中，storm作為實(shí)時(shí)流處理系統(tǒng)，處理的數(shù)據(jù)可能比較大。比如我們用來(lái)進(jìn)行圖像處理，一個(gè)圖片可能有1M左右。這時(shí)候storm的性能如何呢？
2）為了簡(jiǎn)化storm的集成，我們使用DRPC來(lái)訪問(wèn)storm，具體用法可參見(jiàn)[參考2]和[參考3]，在DRPC訪問(wèn)時(shí)，數(shù)據(jù)需要從DRPCClient發(fā)送至DRPCServer，再由DRPCServer發(fā)送給topology中的spout，spoout發(fā)送給Bolt........；當(dāng)數(shù)據(jù)處理完畢后，還要由Bolt返回給DPRCServer，由DRPCServer返回給DRPCClient。
增加了這些步驟以后，Strom DRPC的性能究竟如何呢？
3）作者在[參考1]中提到，使用外部處理程序時(shí)Storm的性能明顯下降，大概只有1/10的性能。但是我們?cè)趯?shí)際使用中，可能經(jīng)常是在已有的基礎(chǔ)上，將功能集成到Storm中運(yùn)行。通俗點(diǎn)說(shuō)：實(shí)際情況是我們經(jīng)常使用外部處理程序，這種情況下，怎么能提高Storm的性能呢？關(guān)于這點(diǎn)可以查看[參考4]。我們使用JNI來(lái)解決。
測(cè)試與結(jié)論
1）測(cè)試環(huán)境
測(cè)試環(huán)境如圖所示
有客戶(hù)端和兩臺(tái)服務(wù)器組成。
客戶(hù)端為虛擬機(jī)，單核3.2GHz 1G 內(nèi)存，100M帶寬。
服務(wù)器也是虛擬機(jī)，8核2.2GHz，8G內(nèi)存，1G帶寬。
DRPC Topology由一個(gè)DRPCSpout，CPPBolt和一個(gè)ReturnResult組成。功能是接收一個(gè)字符串并返回。
Topology運(yùn)行在一個(gè)work中，Spout，Bolt分別由不同的線程執(zhí)行。
2）測(cè)試方法
在Client啟動(dòng)0-100多個(gè)線程，不停的訪問(wèn)Topology，向其發(fā)送一個(gè)字符串（1K-1M）。Topology會(huì)原封不動(dòng)的返回該字符串。
測(cè)試過(guò)程就不詳細(xì)展開(kāi)了。直接說(shuō)測(cè)試結(jié)果。
3）測(cè)試結(jié)論
該測(cè)試中，處理速度主要受限于客戶(hù)端帶寬。也就是說(shuō)由于數(shù)據(jù)量大，客戶(hù)端發(fā)的速度慢，低于Storm中topology的處理速度。
因此該測(cè)試只能得出DRPC方式中單個(gè)請(qǐng)求在不同數(shù)據(jù)大小時(shí)，storm的延遲時(shí)間。
簡(jiǎn)而言之，StormDRPC方式中，最小延遲為50ms（數(shù)據(jù)小于1K），當(dāng)數(shù)據(jù)量大時(shí)，256K數(shù)據(jù)，延遲為125ms，512K時(shí)延遲為208ms。
所以Storm數(shù)據(jù)量較大的時(shí)，處理的延遲還是比較大的。
當(dāng)然以上僅是在特定環(huán)境中的測(cè)試，僅供參考。
改進(jìn)方法
根據(jù)個(gè)人經(jīng)驗(yàn)，針對(duì)以上Storm延遲可以由以下改進(jìn)方法：
1）數(shù)據(jù)可以先壓縮后再交給storm處理，在具體的bolt中對(duì)其進(jìn)行解壓縮。根據(jù)個(gè)人測(cè)試zlib壓縮1M的數(shù)據(jù)，壓縮率為80%，既可以將數(shù)據(jù)研所為原來(lái)的20%。從而可以減小數(shù)據(jù)量，提高效率。而zlib對(duì)1M數(shù)據(jù)進(jìn)行壓縮、解壓縮所用時(shí)間在10ms以?xún)?nèi)。可以使情況選用。見(jiàn)[參考7]
2）storm本身采用字符型傳輸，對(duì)于二進(jìn)制數(shù)據(jù)必須進(jìn)行編碼。可采用base64編碼。參見(jiàn)[參考5]，base64對(duì)1M數(shù)據(jù)的編碼，解碼時(shí)間也分別小于10ms。
3）在DRPC測(cè)試中，數(shù)據(jù)從Clinet到DRPCServer，到DRPC SPOUT，到BOLT，到RETURN Result,在到DRPCSERVER，最后返回Client傳輸多次，可以考慮使用內(nèi)存數(shù)據(jù)庫(kù)如redis，Client直接將數(shù)據(jù)放入redis，將其在redis中的路徑進(jìn)行傳輸，在需要時(shí)，由bolt從redis中獲取。參見(jiàn)[參考8]。將1M數(shù)據(jù)在redis中存取，耗時(shí)也分別在10-20ms。
4）對(duì)于外部處理程序，如C++，可以采用JNI的方式，對(duì)ShellBolt進(jìn)行改進(jìn)，而不是啟動(dòng)新的進(jìn)程在通過(guò)Json編碼，Pipe傳輸與之通訊，從而也可以提交效率。參見(jiàn)[參考4]。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters