線程組里面有三個接口請求，依次為：顯示商品列表、登錄秒殺平台賬戶、進行秒殺
對線程組用5000個線程循環10次
設置一下默認配置，之后就不用反復填寫了
設置配置文件
這個具體功能就是讀text文件並且設置變量的作用。
設置HTTP 請求
我們這次直接對秒殺功能進行壓測，填寫的路徑如圖所示，這個要參見之前的代碼。訪問這個路徑時需要兩個變量，其中token是從之前的文本文件中讀取的（也可以從登錄接口正則獲取到），注意Value的語法（如何寫的）。
結果展示
第一次運行的結果：
TPS：630.9/sec（不高）
錯誤率：64.73%（太高了）
錯誤率太高了，看一下程序，拋異常了。
Redis異常
很明顯，這樣的並發下Redis讀取超時了。貼出Redis的配置：
數據庫超賣現象
這是秒殺商品表，我們是對商品1進行秒殺的，庫存成為負值，問題大了。我之前設置的秒殺商品個數給了9件，現在超賣了22件。
第二次運行結果
為了客觀表現結果，重新再運行一次。注意把數據庫信息清空的清空，恢復的恢復；把JMeter上次結果清空。
壓力報告結果：
TPS：808.5/sec（不高）
錯誤率：67.16%（太高了）
Redis異常
和第一次一樣，就不貼圖了。
數據庫超賣現象
4. 總結
這次實戰結果就是：1. Redis讀取超時拋異常導致壓測的錯誤率太高；2. TPS不高，說明系統性能不佳；3. 數據庫出現超賣現象，嚴重的業務邏輯錯誤。
5. 解決異常
程序拋異常，這是不應該產生的，先將拋異常的問題解決。
我一開始先把redis連接池重新配置：
運行后發現程序不拋異常了，但是壓測的錯誤率並沒有下降，依然在60%以上，意識到這可能不是簡單改動程序就行了。
查看了壓測的日志，也並沒有報錯，如果大家有遇到類似的問題，參考博文：
https://www.cnblogs.com/111testing/p/11437815.html
主要原因是：Windows 提供給 TCP/IP鏈接的端口為 1024-5000，並且要四分鍾來循環回收他們。就導致我們在短時間內跑大量的請求時將端口占滿了。
這個方法我試過了，用了這個方法可以把錯誤率大大降低，但是如果把並發調大還是會出現錯誤。
所以我想是不是本身就是我單機性能有限。可以把並發線程和循環次數適當調小。
原文鏈接：https://blog.csdn.net/Serena0814/article/details/89648174
