如何理解Storm的性能測試報告

本篇文章為大家展示了如何理解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的性能測試報告，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。