因爲在客戶端發request的時候，是不會管服務器的狀態的。
下面打個比方，具體數據，不可做任何參考，只是我臨時編的。
比如：服務器可以同時每秒處理100次點擊，這時，需要調用服務器的一些資源來處理，像：JDBC連接、內存、開socket等等，其他的用戶呢？應該都在排隊狀態，而服務器處理完了前面的用戶後，需要一些時間來釋放這些被佔用的資源，假設爲1秒，如果LR採樣的時長爲2秒，那麼服務器處理的用戶應該爲50次點擊／每秒，按這種理想狀態，點擊率的圖應該是比較平穩的。
但是，系統受的壓力會隨着點擊的增加而增加，系統性能也就慢慢的下降，例如釋放資源的速度開始變慢、換頁開始頻繁，那麼，後面的點擊造成的請求，很有可能需要等待的時間隨機變長。但是採樣的頻率是不變的，所以後面的採樣值應該慢慢的變小。
也就是像有些圖中所顯示的那樣：隨着場景時間的持續，點擊率，吞吐量等圖的曲線慢慢的下降。
而出現超時的現象也很好解釋了，無非是有些請求，等待的時間太長了。
有些圖呢是比較穩定的，曲線平穩，這時可以認爲，系統可以承受當前用戶量的壓力。
而有些場景會出很多超時的錯，這就有可能是系統承受不了這種的壓力，或者配置上有些問題。
需要綜合分析了。