🍅 點擊文末小卡片，免費獲取軟件測試全套資料，資料在手，漲薪更快

根據在之前的壓測過程碰到的問題，今天稍微總結總結，以后方便自己查找。

一、單臺Mac進行壓測時候，壓測客戶端Jmeter啟動超過2000個線程，Jmeter報OOM錯誤，如何解決？

解答：單臺Mac配置內存為8G，可用內存最大為3.5G左右，啟動一個線程將近需要1M內存，2000個線程，需要大概2G左右的內存；然后啟動Jmeter，本身需要將近400M的內存，接著在運行過程中，Jmeter又使用了Respoonse Time、TPS、Thread等等的計數器也會占用額外內存；最后，Jmeter運行不到2分鐘，導致Jmeter閃退，然后Mac OS重啟，原因就是系統出現了Out Of Memory的錯誤。

建議：單臺壓測機器，啟動線程不超過1000個，推薦500個左右，這樣客戶端性能比較好；如果要壓測超過1000個線程，建議分成2臺Mac機器進行壓測，超過2000個，分成3臺Mac機器壓測，以此類推。

二、使用斷言，是否特別消耗系統資源？

解答：使用Response Assertion 和Json Assertion這兩種斷言方式，不是太占用系統CPU資源；但是如果使用正則表達式進行斷言，就會對系統的CPU有一定的消耗。這個好像使用SQL語句一樣，使用Like進行查找結果，是模糊匹配，所以需要額外資源進行計算；如果使用x=y的條件，查詢速度就會快很多。

三、當壓測線程500左右，沒有使用集合點，TPS一直無法上到200以上，并且Error%率很低，不超過1%的錯誤率？

解答：Jmeter在腳本中，使用集合點-synchronizing point，計算TPS的算法跟腳本中沒有使用集合點的TPS算法有區別；所以，當腳本中使用集合點，那么被集合點壓測的接口TPS就會比沒有被集合點壓測接口的TPS高；所以，這個是設置的問題，不是服務器或者應用的問題。

四、頁面性能需要壓測嗎？場景：多人反復登陸/退出/搶紅包/多人提問/多人彈幕......

解答：其實頁面的請求也是通過前端接口傳遞到后端接口，然后通過后端的接口拿到需要的數據，最后傳給前端，讓數據在前端頁面展示；如果后端的接口響應慢，就必然會導致前端展示數據的速度慢；如果后端的響應速度快，前端的展示數據的速度仍然很慢，那么就跟客戶端的機器CPU/內存/瀏覽器等配置相關，需要單獨分析，不能一概而論。

建議：這個問題，一般都是前端的開發工程師提出來的，其實，前端的邏輯相對簡單，主要是數據展示功能，數據的加工工程，都是放在后端來完成的；正常情況下，如果后端的接口響應很多，前端的接口響應速度應該不會慢。頁面的展示功能，其實可以通過“分頁加載”、“延遲加載”、“查詢緩存而不是數據庫獲取數據”等等手段，都可以提高頁面的響應速度，我就不班門弄斧了。

五、當使用Non-GUI模式運行Jmeter時候，TPS可以達到500-600左右，這個是啥原因？

解答：當壓測客戶端，使用命令行模式運行腳本，不是采用GUI模式運行腳本；如果GUI模式壓測的結果是300TPS左右，當切換到命令行模式后，壓測的結果是600TPS左右；這個一般是服務器的配置不一樣、服務器的訪問量不一樣等等原因。正常來說，使用命令行運行腳本，壓測客戶端使用自己的資源會更少，但是，不會影響TPS的指標，因為，你壓測的是服務器，不是你機器本身，跟客戶端的資源沒有半點關系。

六、并發線程數和并發用戶數，是同一概念嗎？

解答：對于loadrunner和jmeter之類常規性能測試工具來說，答案是肯定的；大家可以設置線程數100，循環1次，最后，總的請求數一定是：100。但是對于gatling比較特殊，用的是協程，比線程更小的單位，所以，并發線程數和并發用戶數不能直接畫等號。

七、TPS和QPS的區別是什么？

解答：TPS是每秒鐘處理完的事務次數，一般TPS是對整個系統來講的。一個應用系統1s能完成多少事務處理，一個事務在分布式處理中，可能會對應多個請求。每秒鐘處理完請求的次數；注意這里是處理完。具體是指發出請求到服務器處理完成功返回結果。

對于衡量單個接口服務的處理能力，用QPS比較多。

最后感謝每一個認真閱讀我文章的人，禮尚往來總是要有的，雖然不是什么很值錢的東西，如果你用得到的話可以直接拿走：

這些資料，對于做【軟件測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！凡事要趁早，特別是技術行業，一定要提升技術功底。