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