場景設計-學習筆記之性能誤區
by:授客 QQ：1033553122
場景假設：
每個事務僅包含一次請求，執行10000個并發使用者數
性能誤區：
每秒并發使用者數=每秒向伺服器送出請求數
詳細解答：
每秒并發使用者數，是從用戶端的視角定義的，而每秒請求數，是從伺服器的視角定義的。
請求，從用戶端-->網絡-->伺服器，中間的資料傳遞是需要時間的，是以10000個并發使用者不一定同時到達伺服器端，即每秒并發使用者數 != 每秒并發請求數
此外，如果服務端接收到的請求數太多，超過請求隊列的長度，伺服器忙不過來，那麼超過的部分将駐留在伺服器的線程中，這部分的請求是不會對伺服器端産生真正的負載，是以，每秒并發使用者數 != 每秒并發請求數。
由此可知，常見的類似“伺服器支援10000個并發使用者”的性能需求，是從用戶端的視角定義的，本身就存在一定的不合理性。反過來，從伺服器的視角來定義性能需求--“伺服器每秒能處理10000個并發請求”，似乎就比較合理了，現在的問題是：怎麼樣才能達到這個目的呢？
答案顯而易見，增加用戶端每秒并發使用者數，比如15000(假定伺服器能夠處理這麼多)，這樣同時到達伺服器的請求數就可能達到10000個/秒。
而通常，我們期望測試結果能提供一個相對穩定的每秒請求數(RPS)，要實作這個目的，得依賴持續不斷的請求，是以，一般情況下，我們會對場景設定一個持續運作時間(在這個時間段内進行多次疊代)，通過事務 (transaction) 的取樣平均值來保證測試結果的準确性。
每個虛拟使用者都在接收到來自服務響應後，下一次疊代中，重新發起新的請求，這樣一來，多次的反複疊代運作可能會造成上述說的，請求數大于請求隊列容量。
而我們知道，http本身是基于tcp連接配接的，而tcp連接配接又是同步協定，是以，對于每個虛拟使用者來說，僅當每一個發到伺服器的請求得到響應之後，才會發送下一次請求。而此時，伺服器正處于忙碌的狀态，一時間無法處理所有請求，這樣一來，用戶端接收到請求響應消息的時間間隔變長，甚至逾時失敗。
關鍵的是，當用戶端請求發送出去後，LoadRunner就開始啟動計時器，計算響應時間，直到它收到伺服器端的響應為止。這樣，得出的測試結果可能是：事務平均響應時間很長，最小響應時間與最大響應時間的差距很大，此時的平均響應時間，也就失去了它應有的意義。也就是說，由于用戶端發送的請求太快而導緻影響了實際的測量結果。
為了解決這個問題，我們可以在每兩個事務請求之間插入一個思考時間，這将會降低單個使用者啟動請求的速度。間歇會減少請求線上程中駐留的時間，進而提供更符合現實的響應時間。
最後：
雖然性能測試通常都是從用戶端活動的角度定義的，但是它們應該以伺服器為中心的視角來看待。
作者：授客
QQ：1033553122
全國軟體測試QQ交流群：7156436
Git位址：https://gitee.com/ishouke
友情提示：限于時間倉促，文中可能存在錯誤，歡迎指正、評論！
作者五行缺錢，如果覺得文章對您有幫助，請掃描下邊的二維碼打賞作者，金額随意，您的支援将是我繼續創作的源動力，打賞後如有任何疑問，請聯系我!!!
微信打賞
支付寶打賞 全國軟體測試交流QQ群
