試驗發現，當執行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。

　　那麼這樣的結果有什麼問題呢。總結為一句話：測試環境的業務和真實環境不符，這樣測出的資料沒有價值。即使測試通過，也不能證明真實環境是ok的;或者即使測試不通過，也不能說明真實環境不ok，呵呵。

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

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