開始性能測試前需要了解的內容：
1、項目具體需求。
2、指標：響應時間在多少以內，併發數多少，tps多少，總tps多少，穩定性交易總量多少，事務成功率，交易波動範圍，穩定運行時長，資源利用率，測哪些交易，哪些接口,測試哪些場景。
3、環境：生產環境服務器數量，測試環境服務器數量，按照資源配比得出測試指標。
4、協議：系統用什麼協議進行通訊。
5、壓力機數量：如果併發用戶數太多，需要把壓力發到不同的壓力機，不然可能會存在壓力機瓶頸問題，導致tps和響應時間抖動。
6、交易佔比：分析線上日誌得出tps佔比。
7、系統架構：請求流經過哪些環節，壓測時監控這些環節。
測試：
1、基準：一個用戶迭代100次，關注響應時間，事務成功率100%。
2、負載：10個用戶跑10分鐘，關注響應時間，事務成功率100%。
3、容量：估算一個總tps，根據公式計算出每個交易的pacing和vu，獲取系統最大處理能力（最優容量），再令外測出三個梯度作爲對比（兩組小於最優容量，一組大於最優容量），四組容量VU等差，tps等差，對比每組容量實際佔比和測試佔比（越接近越能模擬真實場景），關注響應時間，總tps，tps，事務成功率，AP cpu利用率，DB cpu利用率，線程死鎖，數據庫死鎖。
其中響應時間應小於負載測試時間，總tps應約等於預估總tps（相差不超過10是正常的），每個交易的tps應接近預估總tps*佔比，事務成功率100%，AP cpu小於60%，DB cpu小於80%。dump線程棧檢測是否有線程死鎖，查看數據庫日誌看是否有數據庫死鎖。
4、穩定性：採取最優容量的80%作爲壓力持續運行24小時，觀察系統長時間運行的性能表現，關注響應時間，tps，總tps，事務成功率，交易總數，觀察是否有內存溢出（堆溢出，棧溢出，持久代溢出），cpu利用率是否達標，mem是否不持續增長，是否能正常觸發fullgc，gc時間，gc頻率， fullgc時間，fullgc頻率（重點關注，JVM調優就是爲了減少fullgc頻率）。
監控：
容量測試和穩定性測試時啓動nmon監控。
壓測中遇到的性能問題及解決辦法：
一、容量測試過程中cpu過高
1、用vmstat實時監控cpu使用情況。很小的壓力AP cpu卻到了80%多，指標是不能超過60%。
2、分析是use cpu過高還是sys cpu過高，常見的是use cpu使用過高。
3、如果是sys cpu使用過高，先把消耗cpu最多的進程找出來（top命令），再找到該線程下消耗cpu過高的是哪幾個線程，再把該線程轉換成16進制，再用jstack命令來dump線程棧，看這個線程棧在調用什麼東西導致use cpu過高。
二、內存溢出（堆溢出、棧溢出、持久代溢出）
1、堆內存溢出
1)穩定性壓測一段時間後，LR報錯，日誌報java.lang.OutOfMemoryError.Java heap space。
2)用jmap -histo pid命令dump堆內存使用情況，查看堆內存排名前20個對象，看是否有自己應用程序的方法，從最高的查起，如果有則檢查該方法是什麼原因造成堆內存溢出。
3)如果前20裏沒有自己的方法，則用jmap -dump來dump堆內存，在用MAT分析dump下來的堆內存，分析導出內存溢出的方法。
4)如果應用程序的方法沒有問題，則需要修改JVM參數，修改xms，xmx，調整堆內存參數，一般是增加堆內存。
2、棧內存溢出
1)穩定性壓測一段時間後，LR報錯，日誌報Java.Lang.StackOverflowError。
2)修改jvm參數，將xss參數改大，增加棧內存。
3)棧溢出一定是做批量操作引起的，減少批處理數據量。
3、持久代溢出
1)穩定性壓測一定時間後，日誌報Java.Lang.OutOfMenoryError.PermGen Space。
2)這種原因是由於類、方法描述、字段描述、常量池、訪問修飾符等一些靜態變量太多，將持久代佔滿導致持久代溢出。
3)修改jvm配置，將XX:MaxPermSize=256參數調大。儘量減少靜態變量。
三、線程死鎖
1、容量測試壓測一段時間後，LR報連接超時。
2、造成這種現象的原因很多，比如帶寬不夠，中間件線程池不夠用，數據庫連接池不夠，連接數佔滿等都會造成連接不上而報超時錯誤。
3、jstack命令dump線程棧，搜索線程棧裏有沒有block，如果有的話就是線程死鎖，找到死鎖的線程，分析對應的代碼。
四、數據庫死鎖
1、容量測試壓測一段時間後，LR報連接超時。
2、造成這種現象的原因很多，比如帶寬不夠，中間件線程池不夠用，數據庫連接池不夠，連接數佔滿等都會造成連接不上而報超時錯誤。
3、數據庫日誌中搜索block，能搜到block的話就是存在數據庫死鎖，找到日誌，查看對應的sql，優化造成死鎖的sql。
五、數據庫連接池不釋放
1、容量測試壓測一段時間後，LR報連接超時。
2、造成這種現象的原因很多，比如帶寬不夠，中間件線程池不夠用，數據庫連接池不夠，連接數佔滿等都會造成連接不上而報超時錯誤。
3、去數據庫查看應用程序到數據庫的連接有多少個（ show full processlist），假如應用程序裏面配置的數據庫連接爲30，在數據庫查看應用程序到數據庫的連接也是30，則表示連接池佔滿了。將配置改成90試試，去數據庫看如果連接到了90，則可以確定是數據庫連接池不釋放導致的。查看代碼，數據庫連接部分是不是有創建連接但是沒有關閉連接的情況。基本就是這種情況導致的，修改代碼即可。
六、TPS上不去
1、壓力大的時候tps頻繁抖動，導致總tps上不去。查看是否有fullgc（tail -f gc_mSrv1.log | grep full）。
2、pacing設置太小也會導致tps上不去，對抖動大的交易多增加點用戶即可。
3、tps抖動，單壓抖動大的交易，發現很平穩，這時懷疑是不是壓力太大導致，所以發容量的時候把壓力最大的那隻交易分到其他壓力機，然後發現tps不抖動了。注意：多臺壓力機隻影響tps抖動，不會影響服務器的cpu。
4、看響應時間有沒有超時，看用戶數夠不夠。
七、服務器壓力不均衡（相差1%-2%是正常的）
1、跑最優容量的時候，四臺AP只有一臺cpu超過60%，其他三臺都在60%以下。
2、查看服務器是否有定時任務。
3、查看是否存在壓力機瓶頸。
4、是否存在帶寬瓶頸（局域網不存在此問題）。
5、查看部署的版本，配置是否一樣。
6、可能別人也在用這些AP，因爲同一臺物理機上有很多虛擬機，因爲別人先用，資源被別人先佔了。
八、fullgc時間太長
1、跑容量和穩定性的時候，出現LR報請求超時錯誤，查看後臺日誌是fullgc了，看LR幾點報的錯和日誌裏fullgc的時間是否對應，fullgc會暫停整個應用程序，導致LR前端沒響應，所以報錯，這時可以減少old代內存，從而減少fullgc時間，減少fullgc時間LR就不會報錯，讓用戶幾乎感覺不到應用程序暫停。
2、四臺AP輪流着full gc（部分server fullgc，其他server也會fullgc），這時可以制定策略讓不同的server不同時fullgc，或者等夜間交易量少時寫定時任務重啓服務。
注意：
服務器日誌爲error下測試。
服務啓動後幾分鐘內發壓壓力會很大，最好是服務啓動兩三分鐘後再開始跑壓力。
參考：http://mp.weixin.qq.com/s?__biz=MjM5OTI2MTQ3OA==&mid=2652178041&idx=3&sn=8ffbc76d57171f89f7e6a1bd2945d574&chksm=bcdf82308ba80b26cc5cc969ac4434a362d4d7e7a68b119948a731ee9a4cd5de08dc6f0e0087&mpshare=1&scene=1&srcid=1206Xuvf8yKMxpMHIKq94bnO#rd