共計 1256 個字符，預計需要花費 4 分鐘才能閱讀完成。
本篇文章為大家展示了如何理解 Storm 的性能測試報告，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
在一次面試的過程之中，有 CTO 詳細的詢問了 對于機器性能的測試，如下所示：
配置如下：
1 Cpu 8 核 ×2 臺機器
2 主頻 2.26
3 操作系統 redhat
4 網絡千 M 的以太網
5 Storm 的版本號：0.6.1
測試方法
Storm 是一個流處理系統，它以 tuple 為基本單位，每個 tuple 可以包含多個字段（field）。我們給 tuple 定義兩個字段：
Data：存放原始的數據，這里是 1000 字節的數據，此測試中我們僅僅是直接的轉發數據，所以唯一的處理開銷就是 1000 字節的內存拷貝
ltsInfo：時間戳信息，每經過一個處理模塊，我們就在此字段中追加上當時的時間戳，最后統計模塊就可以根據這些時間信息計算出總延遲等。由于不同的機器時間戳并不同步，這給計算延遲帶來了固有誤差，解決的辦法就是把數據發送模塊和最后的統計模塊放到一臺物理機上。
關于在分布式集群上測試 storm 的一個說明：在 storm 上，我們很難給某個模塊（component）指定其運行的物理機，storm 總是自動的把任務平均分配給集群中的各個機器，因此在測試中我們將使用 storm 的工作方式來擴展，而非設計非典型的情景（給某個 component 指定特定的機器來運行，從而打破這種平均分配原則）。
也就是采取了淘測試的機制來處理
內存的使用
淘寶的測試結果為 2 萬條 / 秒左右。
在我本地機器上測試是超過了 2.5 萬條，其中的區別可能是淘寶在測試的過程之中加入了一些時間 TimeStamp。
到目前位置還沒有新加機器來進行一些橫向的擴展。沒有對比新加入的機器對于系統集群的計算能力有多少增加。
具體的測試方式請參考
淘測試的連接：
http://blog.linezing.com/?p=1048 replytocom=828
在我們的實際測試之中，GC 將對于數據的處理造成比較大的速度的改變。Tuple 的處理會積壓是一個特別常見現象。
測試結論
經過上面的測試我們可以得出以下的結論：
storm 單條流水線的處理能力大約為 20000 tupe/s, (每個 tuple 大小為 1000 字節)
storm 系統本省的處理延遲為毫秒級
在集群中橫向擴展可以增加系統的處理能力，實測結果為 1.6 倍
Storm 中大量的使用了線程，即使單條處理流水線的系統，也有十幾個線程在同時運行，所以幾乎所有的 16 個 CPU 都在運行狀態，load average 約為 3.5
Jvm GC 一般情況下對系統性能影響有限，但是內存緊張時，GC 會成為系統性能的瓶頸
使用外部處理程序性能下降明顯，所以在高性能要求下，盡量使用 storm 內建的處理模式
測試的工具是用的：nmon
上述內容就是如何理解 Storm 的性能測試報告，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注丸趣 TV 行業資訊頻道。
