每個專案開發完成必然要經過各種測試，也會進行壓測一下，判斷開發完成的系統的可支撐併發量，我選用目前常用的jmeter,

下載完成解壓，雙擊jmeter.bat即可啟動(或者直接命令號啟動)，如圖：

啟動後，

語言版本選擇：

新增執行緒組：

配置http頭資訊：

正常登陸都帶有cookie、token，這裡配置

cookie配置：

新增值：

檢視結果樹：

彙總圖：

新增一個測試介面請求：

填寫引數和url如圖：

執行緒組設定，為50個執行緒，迴圈2次：

1：執行緒數：併發數量，能跑多少量。具體說是一次存在多少使用者同時訪問
2：Rame-Up Period(in seconds):表示JMeter每隔多少秒發動併發。理解成準備時長：設定虛擬使用者數需要多長時間全部啟動。如果執行緒數是20，準備時長為10，那麼需要10秒鐘啟動20個數量，也就是每秒鐘啟動2個執行緒。
3：迴圈次數：這個設定不會改變併發數，可以延長併發時間。總請求數=執行緒數*迴圈次數
4：排程器：設定壓測的啟動時間、結束時間、持續時間和啟動延遲時間。
 

啟動開始壓測：

分析壓測結果：

檢視結果樹：

檢視彙總圖：

紅框結果解析：

Label：每個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這裡顯示的就是 Name 屬性的值
#Samples：表示你這次測試中一共發出了多少個請求，如果模擬10個使用者，每個使用者迭代10次，那麼這裡顯示100
Average：平均響應時間——預設情況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也可以以Transaction 為單位顯示平均響應時間
Median：中位數，也就是 50％ 使用者的響應時間
90% Line：90％ 使用者的響應時間
Note：關於 50％ 和 90％ 併發使用者數的含義，請參考下文
http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html
Min：最小響應時間
Max：最大響應時間
Error%：本次測試中出現錯誤的請求的數量/請求的總數
Throughput：吞吐量——預設情況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也可以表示類似 LoadRunner 的 Transaction per Second 數，
KB/Sec：每秒從伺服器端接收到的資料量，相當於LoadRunner中的Throughput/Sec

壓測後結果分析：
1：有錯誤率同開發確認，確定是否允許錯誤的發生或者錯誤率允許在多大的範圍內；

2：Throughput吞吐量每秒請求的數大於併發數，則可以慢慢的往上面增加；若在壓測的機器效能很好的情況下，出現吞吐量小於併發數，說明併發數不能再增加了，可以慢慢的往下減，找到最佳的併發數；

3：壓測結束，·登陸相應的web伺服器檢視CPU等效能指標，進行資料的分析;:

4：最大的tps:不斷的增加併發數，加到tps達到一定值開始出現下降，那麼那個值就是最大的tps。

5：最大的併發數：最大的併發數和最大的tps是不同的概率，一般不斷增加併發數，達到一個值後，伺服器出現請求超時，則可認為該值為最大的併發數。
6：壓測過程出現效能瓶頸，若壓力機工作管理員檢視到的cpu、網路和cpu都正常，未達到90%以上，則可以說明伺服器有問題，壓力機沒有問題。:

7：通常影響效能考慮點包括：資料庫、應用程式、中介軟體（tomact、Nginx）、網路和作業系統等方面
 

提交的資料較多容易卡，這裡遇到這個修改記憶體後不生效問題(jmeter5版本)，有大佬指定指點下，

修改的程式碼：

修改啟動後：