性能測試實戰中，為什么要設置考慮時間？

性能測試實戰中，為什么要設置考慮時間？    性能測試

      先說一個概念：吞吐量，這指的是服務器系統（包括軟件和硬件）單位時間內處理業務的數量。我們現在做一個小試驗，寫一個小程序，執行一個簡單的業務，并且在程序中進行計時，計算每分鐘能執行多少次。然后當我們運行1路這個程序的時候，每分鐘能完成約6萬次。好，現在問一個問題，如果我們起2路，是不是每一路都能達到 6萬/分鐘 的吞吐量？

        試驗發現，當運行2路的時候，兩個程序的數值都降了下來，但是它們的總和仍然是6萬次。而且不管我們起多少路，這些程序的性能總和都接近于6萬。

        這就好像一個人1分鐘最快能吃1個饅頭，你讓他一個一個吃，他兩分鐘能吃2個，如果你讓他一手拿一個，同時吃，他兩分鐘吃不了4個，還是只能吃兩個。

        我們不是在說“考慮時間”么，哈哈，別急，因為上面的問題必須要先說清楚。

        如果我們需要進行性能測試的業務是一個單純的業務，就好像上面舉的那個例子一樣，那么測試腳本中就不需要設置“考慮時間”，因為不管你用什么方法測試，一個服務系統處理單一業務的吞吐量總是一個定值。

        但是在實際環境里面，往往一個系統都是要處理多種業務，并且這些業務之間是有邏輯關系的。舉例說明，比如一個論壇系統，每天最常處理的業務有兩個：A打開帖子、B回復帖子。那么每天系統處理AB業務的總數是不是一樣的呢，答案很明顯，看帖子多，回復的少一些。假設A:B=2:1。

        好，如果我們不設置考慮時間，起2路A的腳本，1路B的腳本進行性能測試，我們會得到什么結果呢？我們會得到這兩個業務的吞吐量，并且能算出每個小時系統完成A、B業務的總數，吞吐量 × 時間 ＝ 總數。

        這時我們發現，同樣時間，AB業務的處理總數卻不是2:1的關系，這是為什么呢？原因是這樣的，我們在跑AB腳本的時候，這兩組腳本都在盡全力爭奪服務器的資源，他們的并發路數雖然是2:1，但是給服務器的壓力卻不一定是2:1，可能會出現偏差，測試結果就是最好的證據。A查看帖子由于響應時間短，因此跑的次數更多，最后的比例可能是4:1。

        那么這樣的結果有什么問題呢?？偨Y為一句話：測試環境的業務和真實環境不符，這樣測出的數據沒有價值。即使測試通過，也不能證明真實環境是ok的；或者即使測試不通過，也不能說明真實環境不ok，呵呵。

        比如上面的例子，如果我們測出的結果是B回復帖子的吞吐量不夠，響應時間太長，那可能是因為A業務搶走了過多的，本不屬于A的資源，而引起了B的性能降低。

        說到這里，大家應該明白了，我們設置考慮時間，是為了保證測試復合業務的時候，各個業務之間的比例關系符合我們的真實生產環境。

原文轉自：http://www.anti-gravitydesign.com