The pacing let you control the time between iterations. Thepace tells the Vuser how long to wait between iterations of your actions。
Vuser think time emulates the time that a real user waitsbetween actions. For example, when a user receives data from a server, the usermay wait several seconds to review the data before responding. This delay isknown as the think time.
爲了更好的講清楚，引入iteration的概念。Iteration，迭代。通過設置，可以指定虛擬用戶在同一個Action中重複執行多次，每次重複稱之爲一個iteration。Iteration可以幫助我們模擬現實世界的重複場景。
Pacing，步調。可以通過設置兩次迭代之間的間隔時間，來調整各個action之間的步調（或者稱之爲節奏）。從定義上來看，Pacing是和iteration綁定在一起的，可以認爲是iterationpacing。
Think time，思考時間。可以通過設置思考時間，來模擬真實用戶在操作過程中的等待時間。從定義上來看，thinktime是在iteration內部的某個action中各個步驟的間隔時間。
到這裏，已經能看出兩者之間的區別，但是容易混淆的。接下來通過一個例子來進一步說明，期望能夠深入淺出。
淘寶購物車應用，假定每分鐘有6000個在線用戶瀏覽（Browser），共10臺服務器。用戶在瀏覽過程中，先打開購物車頁面，花了1秒鐘時間瀏覽整個頁面，然後查看其中的某個寶貝。此時，在性能測試場景中（如果模擬真實場景的話），就會在兩個步驟之間設置一個等待時間thinktime = 1 秒。如下圖1-1所示：
假設用戶進行一次上述操作會消耗5秒鐘的時間，即完成整個迭代需要5秒鐘。如果用戶不停頓，繼續第二次重複操作，則同樣耗費約5秒左右的時間。但是真 實世界中肯定是有停頓的。一個真正的用戶，做完一系列操作後，會間隔一段時間。假定用戶停頓了5秒，再第二次重複操作，則一共耗費10秒鐘時間。映射到loadrunner中，就需要在一次iteration中，設置一個thinktime = 1秒，然後在兩個iteration之間，設置一個pacing爲5秒。如下圖1-2所示：
一個虛擬用戶在1分鐘內，就能完成6次的迭代，12次請求。而要達到有6000個用戶的瀏覽量，我們需要6000/12/10= 50個虛擬用戶。
通過上面的例子，相信大家對pacing和thinktime已經有了相應的理解。至於在loadrunner中符合使用、怎樣配置，則可以通過幫助文檔來加深認識。在此不一一說明。
儘管性能測試的需求通常都是從客戶端角度來定義的，比如“系統需要支撐100個併發用戶”、“每分鐘有6000個請求量”，但是壓力應該以服務器爲中 心來看待。原因很簡單，從loadrunenr端發送出去的請求，需要等待服務器端響應之後才能發送下一個請求。可以說，對於每個虛擬用戶，它對服務器發 送請求的頻率取決於服務器對請求的處理時間。
如果需要模擬真實用戶的操作，從而模擬服務器端的真實變動，think time和pacing是兩個必不可少的設置項。
評論：
詞馨：“講解很清晰，pacing和thinktime一目瞭然。
從以上使用場景來看，pacing和thinktime都是可以模仿真實世界中的停頓。這是從客戶端考慮的。
從服務器端考慮，這兩個參數的設置將會更加複雜。
例如，我們需要衡量服務器處理一個請求的平均響應時間。考慮，服務器端能同時併發處理的請求數一定，當性能測試發送的每秒請求數超過它能處理的請求數 後，再到達的請求將會在服務器系統中排隊等待，這時，整個響應時間的計時已經開始，排隊等待時間將會計入響應時間。所以，如果LR仍然持續發送請求，可能 造成接下來的請求都在等待。這時，服務器每次處理的事務數在下降，平均響應時間在增大，造成了請求發送越快，處理越少越慢。
對於這種情況，從服務器端出發，來考慮設置請求發送的速度。”
悟石：“從服務器端來看，讓每顆CPU都忙碌起來，是件好事。當壓力超過CPU能承受範圍時，認爲是過載，等待隊列會越來越長，load不斷飆升。
但如果真實情況是存在瞬間超高壓，中間會有停頓的話，服務器或許能撐得過去（風險很大）。對於複雜場景，這個停頓要靠pacing來完成。不過，pacing怎麼設置才最合適，是需要研究用戶行爲才能定的。”