STORM性能壓測步驟記錄及總結
壓測前的准備
1.明確壓測計划和方案。
(1).首先確定本次壓測的目的是什么。
(2).例如是驗證目標工程是否能夠達到預定的性能指標，還是需要通過調整壓測資源的分配，經過多次壓測比對結果，發現性能瓶頸的所在。
(3).壓測指標一般來說是根據往年同時段或者最近一次大促峰值的數據量按照一定比例增加后評估得出的。
可能會影響性能幾個因素：
a. 機器數、
b. worker數、
c. 執行器數（這里體現為worker數和執行器的配比）、
d. 接收topic的partition數
e. 程序代碼內部的邏輯復雜度
壓測指標
a. CUP使用情況；
b. 內存使用情況；
c. 最大瞬間處理峰值TPS；
d. 持續峰值TPS（能夠持續三分鍾以上的最大值）；
e. 平均TPS；
f. spout數據下發到每個partition是否均勻；
g. 網絡IO；
2. 准備好壓測所需要的數據。
(1)一般來說需要根據壓測指標的tps來准備相應數量的數據，盡量保證灌入的數據可以持續處理10分鍾以上，時間太短的話不足以保證數據處理的穩定性。
(2)確定數據是否可以重復灌入。由於可能需要進行多次壓測，或者壓測數據不夠的時候，首先要確定可否重復使用數據，比如需要將第一次接收的數據存入redis或者hbase表中，后面存在去重或者其他重復數據處理邏輯，那么使用重復數據就會對壓測結果造成影響。
3.提前報備
進行壓測之前先在群中知會一下，以免有其他人同時在進行別的操作而對壓測結果造成影響。
4. 對壓測拓撲對象進行分析。
a.確定拓撲中有多少spout和bolt，搞清楚它們之間的聯系和處理邏輯，確定有多少種日志需要進行壓測，單場景還是混合場景。
b.對於涉及到數據寫入redis、hbase、hive等，如果存在去重或者其他重復數據處理邏輯，需要在壓測前將其進行清空處理。
5.提前打開對應服務器上cpu等監控界面
查看cpu和內存： /nmon下 ./nmon_x86_64_centos6
如果有專門的監控頁面或工具（如zabbix等）則會更加便捷，能夠一站式的監控多項指標。
壓測步驟
第一步：向kafka灌入數據
注：發送數據之前一定要保證storm UI上的對應拓撲已經殺死或者是Deactive狀態，否則數據發送之后會馬上被消費掉，無法堆積到大量的數據達到壓測效果。
直接在服務器上向kafka發送數據
此方法需要先將事先准備好的壓測數據上傳至服務器上，使用linux命令進行數據發送。
注：此方法可能出現灌入數據在分區上分布不均勻的情況，酌情使用。
cat /data/testdata/10033593/kafkadata/storm-expose-access/10.246.4* | /home/storm/software/kafka/bin/kafka-console-producer.sh --broker-list "broker地址" --topic storm_expose_access
第二步：啟動拓撲並記錄監控數據
當灌入數據達到預期達到之前預估的量的時候（保證灌入的數據可以持續處理10分鍾以上），就可以開始進行壓測了。
- 使用拓撲啟動命令啟動拓撲。
- 打開storm UI界面，進行數據記錄。
- 如果配置有監控界面，可直接采用讀取監控頁面的數據來進行指標檢測和記錄。
由於拓撲內部進程完全啟動需要一定的時間，因此在前幾十秒中，是不進行數據處理的。因此最好從1min后再開始進行記錄。
- Cpu監控
待cpu穩定后，觀察cpu利用率是否在正常范圍內，一般是75%以下。
- 查看拓撲進程分布
由於當拓撲分配多個worker的時候，拓撲進程可能隨機分布到storm UI上面的幾個服務器上，因此需要確定哪幾台。
(1) 到storm UI上面查看集群所在的服務器
(2) 分別到這幾台服務器上查看目標拓撲的進程號，查詢不到時表示目標拓撲在該服務器上沒有分配進程
查詢命令： jps –m （或jps –m | grep 拓撲名）
下圖中24922 即為dfp_sa_log在該台服務器上的進程號（一台服務器上可以有多個）
- 查看內存FullGC次數
根據年老代分區的內存變化情況判斷JVM是否進行FullGC，記錄內存在監控時間段內的FullGC次數。
應該盡可能減少Full GC的次數。在對JVM調優的過程中，很大一部分工作就是對於FullGC的調節
根據上面的方法得到的目標拓撲的進程號，可以查看該進程在當前服務器上的FullGC次數。
查詢命令：jstat -gcutil +進程號
第三步：根據監控數據進行分析調整
1． Tps
選擇兩個時間點記錄的數據量，取差值除以時間差，可得出tps。盡量選取時間間隔較長的進行計算，這樣得出的結果屬於系統穩定之后的數據，一般比較接近真實情況。
（1）當計算得出的tps跟預期指標相差不大時，說明當前系統可以滿足性能要求。將壓測過程中的數據記錄下來整理成文檔即可。
（2）當監控到的tps與預期指標相差甚遠的時候，就需要對壓測過程中可能造成tps上不去的原因進行定位分析了。
i.查看壓測過程中拓撲中各個spout和bolt對應的capacity值，如果非常接近於1，或者已經超過1，則說明該spout/bolt已經達到處理極限。此時可對其分配幾個excutor再壓壓看
ii. Spout的執行器數太少。當spout分配的執行器數小於topic分區數的時候，可能會造成接收到的數據不能及時下發給處理單元，造成tps過低，可以增加執行器數（excutor）數等於分區數在進行觀察
iii.Topic分區影響，當tps相對於壓測指標過低，同時各個bolt的capacity值都沒有達到處理極限時，可能是topic分區較少從而入口接收數據的能力達不到造成的。可建議后期增加topic的分區數。
iv. Redis讀取/寫入影響，如果邏輯中存在redis讀取或者寫入操作的時候，可能也會對tps造成影響
v.邏輯太重導致，如關聯mysql維表或者hbase
vi.外部rsf接口影響
2． Cpu
待cpu穩定后，觀察cpu利用率，如果在75%以下則表示正常
如果CPU利用率過高，可以使用top命令查看當前占用率較高的是哪些進程，具體想要分析出cpu高的問題還需要其他手段。
3． 內存FullGC
如果內存FullGC過於頻繁，則說明該拓撲處理過程中內存消耗過大，短時間內就需要清空一下內存，需要進行優化；或者也可能跟應用的邏輯和分配的資源有關。
通過jmap dump了jvm的堆內存，用visualvm查看dump出來的文件，進行進一步的分析調優。
一般來說，測試環境與實際生產環境上的資源配置相差較大，因此我們在測試環境上得出的結果一般與生產還是有一定差異。這可能就需要我們通過按照一定的比例調整測試環境上的配置資源數，分別得出分配不同資源時的結果，然后再根據這些結果進行線性估算得出在生產上可能需要的資源數，壓測結果可供調整生產環境時進行參考。