本節書摘來自異步社群《loadrunner 12七天速成寶典》一書中的第2章，第2.6節第二個性能測試案例，作者陳霁，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
2.6 第二個性能測試案例
雲雲：烤魚吃得很爽。
戀戀：就是你非要吃香辣味的，害得我嘴巴都麻了。
雲雲：香辣味的好吃，就是鲶魚吃得有點膩，能吃黑魚就好了。
戀戀：下次多找幾個人一起吃飯啊，這下他們生意就更好了。
雲雲：那麼我問你一下點一樣的魚和點不同的魚有什麼差別？
戀戀：嘿，你又要考我啦，其實剛才你還沒提問，我腦子裡面就在想這個問題了。
雲雲：哦，美美狗開竅了？
戀戀：不但我是美美狗還是聰聰狗，你那點小花樣我早看出來了。
雲雲：那麼你說說，讓我欣賞一下你的“光芒”。
戀戀：這個問題按照你的思路，我可以先從我公司門口的食堂說起，一般食堂都有固定的菜色，因為燒同樣的東西處理能力強、成本低，而如果為每一個顧客單獨炒菜，那麼成本就會高很多。
雲雲：你這個跑題有點遠啊！
戀戀：是以作為顧客，我們一般幾個人都點相同的菜，這樣廚子燒的快，無論從配菜，到燒菜都會并行處理。總的來說就是，如果每個人都要不同的東西，會讓一個飯店很忙，處理能力降低，而如果要的東西類似，那麼就會極大地提高處理效率，進而增加營業額。
雲雲：哎喲，貌似靠譜了。
戀戀：作為軟體系統來說也是這樣，如果每次對伺服器發出的請求不同，那麼伺服器也會為每一個請求單獨計算，進而會讓伺服器很忙，提高效率就是要讓客戶做的事情盡量相同，然後伺服器就可以并行處理了。
雲雲：嗯，不錯，不過有些不太專業。
戀戀：比如a和b做相同的請求，那麼對于資料庫來說查詢的内容都相同，那麼就可以隻計算一次，然後内容就可以一次發給客戶啦，就好像兩個人都點宮保雞丁炒飯一樣，一次炒制，兩盤出鍋。
雲雲：雖然請求相同，但是可能因為業務不同而導緻結果不同啊，比如a是管理者能看所有的記錄，而b是普通使用者隻能看自己的記錄！
戀戀：這個……
雲雲：那你覺得請求應該相同還是不相同呢？
戀戀：我覺得請求應該不同，因為你既然讓我把腳本動起來，還給我說怎麼做參數變量、處理業務，本質上就是要讓每次輸入的東西都不一樣。
雲雲：沒錯，如果每次請求都一樣，那麼伺服器會自動使用cache機制，這也是一個使伺服器提高處理能力的政策，當發現請求或者查詢内容相同，系統會先從緩存（記憶體）中查找是否存在比對的記錄，如果有就傳回，否則就執行一次，将結果存放入緩存，唯一特例就是所謂的要做及時查詢，就是鎖概念。
戀戀：嗯，我也聽說過什麼memcache、pga&sga還有啥jvm記憶體管理，都是和緩存有關系，鎖這個概念我就不太懂了。
雲雲：鎖這個概念怎麼說呢，這樣吧，你知道12306買火車票難吧。
戀戀：知道啊，不知道誰做那麼差個系統，查個火車票都經常刷不出來。
雲雲：這就叫做外行看熱鬧，内行看門道。其實做火車訂票系統是很難的，因為查票是及時的，要鎖定票。
戀戀：go on！
雲雲：每當一張票被訂的時候，所有的查詢都要得到全新的少了一張票的情況，所有的訂票都要告訴别人這個位置的這個票已經被訂了。是以當成千上萬的人去買票的時候，一張票被鎖定會影響幾萬個查詢，每次查詢都不能用cache，否則會得到錯誤的資訊，你明明看到這個票有，但是訂的時候卻失敗。
雲雲：這裡面還有更複雜的業務，比如從上海到北京的高鐵，如果我訂了一張從南京到天津的票，就意味着會多一張上海到南京的票，還有一張從天津到北京的票！
戀戀：那麼怎麼優化呢？
雲雲：很簡單，首先不要做及時查詢，例如不要直接給每個客戶看有多少張剩票，其次當一張票訂了後，不要立即計算出可能導緻生成的部分路程的票，最後将坐全程的票和坐半程的票位置分開做表分離，這樣就算買了半程票影響的記錄會比較少，處理起來相對簡單，讓專門的伺服器去處理多程票！
戀戀：來吃個梨，你看又進入狀态了吧，後面一個人就亢奮的說啊說啊，完全不管别人懂不懂。
雲雲：真是好心沒有好報，看在你給我削梨的舉動上就原諒你了。睡覺前是不是可以做第二個性能測試案例了啊。
戀戀：今天晚上要做啥啊？
雲雲：做一個腳本比較一下點選相同的文章和點選不同的文章的性能有何差別！
戀戀：好，開工。
**小結
了解動态通路會帶來的負載點及系統處理業務的邏輯概念。
錄制腳本運作
**
戀戀：打開lr啟動vugen錄制一個腳本。
雲雲：别忘了你首先要有那麼多文章，否則你查詢不到。
戀戀：對，那麼先錄一個生成文章的腳本吧。
（幾分鐘過去後）
戀戀：腳本生成。
戀戀：這裡我用了一個循環，做了1000次。
雲雲：那麼你發帖的那個參數是？
戀戀：{topic}啊，這是我定義的一個時間參數，這樣每次文章都不一樣，如圖2-23所示。
雲雲：哎喲，不錯哦。
戀戀：好了，單擊運作，我去給你削個梨。
雲雲：好！不過，如果你用場景，運作會快一些。
戀戀：好啊，你自己削梨去，eq真低。
雲雲：我錯了，還是你幫我削吧。
（幾分鐘後，文章生成）如圖2-24所示。
戀戀：接着我要錄制一個使用者随機通路文章的腳本和一個使用者通路一個固定文章的腳本。
戀戀：找到看帖請求的那個函數，然後将這個請求内容做一個參數化，參數名稱叫作tid，并且設定從1～1000的随機數，如圖2-25所示。
戀戀：最後還要在查詢前後加個事務，讓腳本運作的時候能夠統計響應時間，先來試着運作一下。
戀戀：代碼運作大功告成！
雲雲：值得表揚！
（分别運作未參數化和參數化過的腳本）。
戀戀：好像查詢條件是随機的會慢一點。
雲雲：go on。
戀戀：ok，搞定兩個腳本，一個是原腳本，查詢條件不變的；還有一個是查詢條件是随機的内容，接着分别到場景裡面去運作一下。
戀戀：場景裡面要添加監控内容（windows資源），單擊開始運作。