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出來的檔案，進行進一步的分析調優。
一般來說，測試環境與實際生產環境上的資源配置相差較大，因此我們在測試環境上得出的結果一般與生產還是有一定差異。這可能就需要我們通過按照一定的比例調整測試環境上的配置資源數，分別得出分配不同資源時的結果，然後再根據這些結果進行線性估算得出在生產上可能需要的資源數，壓測結果可供調整生產環境時進行參考。
關於程式效能及優化
作為程式設計師經常被提及要對自己的 負責，要盡可能的優化我們寫的 保證高效性 時間和空間的效率都要考慮 尤其是我們在去微軟這類公司面試的時候，經常會被要求做這些優化的遊戲。於是我們會有一種感覺，看到一段 就想去進行優化，力求演算法更優，行數更少。雖然很多時候 行數並不影響我們的程式執行效率，但是程式...
關於mysql效能壓測之tpcc
wget 安裝依賴 yum install y mysql devel 解壓安裝 tar xf tpcc mysql src.tar make 測試前準備 root tpcc mysql mysql uroot p123456 s data mysql 5.5 mysql.sock e create...
CPU效能壓測
有時候為了專案需求需要對cpu效能做乙個壓力測試，這裡提供一種方法。通過對圓周率位數進行計算進而確定cpu效能，根據定義預計執行時間，具體操作如下 time echo scale 1000 4 a 1 bc l q 通過該命令執行，如果3 4分鐘沒有出現結果，基本問題就可以定位在cpu上，這裡我通過...