關於效能測試理解：
1、對於壓測應用的單臺機器的極限情況下，95線，99線，QPS，是否存在OldGC情況。


一般極限情況，CPU或者記憶體的佔用率達到90%左右，為了壓測到這個極限值，併發數和迴圈數的設定是否有什麼設定原則？
例如，
1）併發200，迴圈5000次，共100萬請求，壓測結果發現沒有達到極限值預期
2）併發100，迴圈10000次，共100萬請求，壓測結果仍然沒有達到極限值預期
3）併發80，迴圈20000次，共160萬請求，恰好複合預期，CPU佔比90%左右


上面第3點併發數和迴圈數這樣的設定是否合理？是不是所有的設定都是以達到我的預期目的為條件就可以？（CPU佔比90%左右）




2、併發數和迴圈數，通常情況下，哪個因素的值對CPU和記憶體的影響更大些？


3、JVM 這個指標的含義和檢視以及調優方式有哪些？老師能否解釋一下。


4、對於OldGC的監控，壓測過程中，可以通過哪些方式檢視到？


5、關於聚合報告中記錄的QPS值和受壓機監控平臺上獲得的QPS值，理論上這2者是否是應該相等的？如果實際情況中有區別，可能是哪些因素導致的？










1、對於壓測應用的單臺機器的極限情況下，95線，99線，QPS，是否存在OldGC情況。


A:  95線，99線，是從響應時間的角度進行度量的效能指標，主要評估使用者對響應及時性的要求。
QPS是從吞吐量角度度量的效能指標，主要是評估服務的吞吐能力。
OldGC是JVM Old區gc的效能指標，你這裡給的不知道具體是指什麼，一般包括GC次數，GC時間等。這個指標會對吞吐量和響應時間有一定影響，也要取決於你的gc是怎麼配置的。


一般極限情況，CPU或者記憶體的佔用率達到90%左右，為了壓測到這個極限值，併發數和迴圈數的設定是否有什麼設定原則？
例如，
1）併發200，迴圈5000次，共100萬請求，壓測結果發現沒有達到極限值預期
2）併發100，迴圈10000次，共100萬請求，壓測結果仍然沒有達到極限值預期
3）併發80，迴圈20000次，共160萬請求，恰好複合預期，CPU佔比90%左右


上面第3點併發數和迴圈數這樣的設定是否合理？是不是所有的設定都是以達到我的預期目的為條件就可以？（CPU佔比90%左右）
A：
併發數是模擬虛擬使用者對服務端的操作，併發數越大，向服務端傳送請求的速度越快，服務端的壓力自然會越大。
迴圈次數控制的是執行次數，從另外一個角度來看，執行次數越大測試時長就會越長，這個壓力對服務的施壓持續時間，有些情況下，施壓時間比較長，會暴漏一些長時間壓力下才會出現的問題，比如資源洩露問題。
這兩個是不同的角度，請弄清楚，不要混淆。


2、併發數和迴圈數，通常情況下，哪個因素的值對CPU和記憶體的影響更大些？


A：併發數的增加會對服務端的壓力逐步增加，但是影響因素不確定，取決於你是什麼樣的服務，CPU密集型還是網路IO密集型等。總之併發數的增加，相應的資源會隨之增加。
迴圈次數，之前講了，是壓力保持多長時間，持久在這個壓力下服務端的表現是否足夠穩定。


3、JVM 這個指標的含義和檢視以及調優方式有哪些？老師能否解釋一下。
A：這個太多了。推薦看看書籍《深入理解Java虛擬機器》


4、對於OldGC的監控，壓測過程中，可以通過哪些方式檢視到？
A：你可以通過java自帶的一些工具進行監控，jvisualVM，Jconsole，jstat，jmap等，都可以去監控。


5、關於聚合報告中記錄的QPS值和受壓機監控平臺上獲得的QPS值，理論上這2者是否是應該相等的？如果實際情況中有區別，可能是哪些因素導致的？


A：聚合報告上的Qps和監控平臺上獲取的QPS理論上應該是相當的。
如果不相等，可能有幾個原因：
 你客戶端統計的qps不對，比如沒有做正確性驗證，把錯誤的請求也統計進來了
可能是你監控統計平臺統計的方法不對
可能你客戶端和服務端統計的角度不一樣