在某個業務場景中，包含資料建立和資料查詢兩項業務；現需考察資料建立和資料查詢兩項業務在併發比例為2:1、總併發量為100使用者情況下的混合響應時間。
對混合比例的設定，可直接在指令碼中進行，即通過隨機函式rand實現，指令碼設計如下所示。
int該種方式的優缺點對比：num;
action
()else
lr_end_transaction
("綜合業務--資料建立與資料查詢"
,lr_auto
);return0;
}
優點：
缺點：
在業務型別較多，混合業務場景較為複雜的情況下，採用修改指令碼的方式會比較麻煩。例如，若共有5種業務型別，現需要對其任意兩種業務的混合場景進行壓力測試，如果仍採用第一種方式，那麼我們就必須得針對兩兩業務的混合情況，建立10個混合業務指令碼。當業務型別更多，或者混合場景更為複雜（如需考慮任意三種、任意四種業務等的混合情況）時，指令碼的建立量會大大增加，且均為乏味的重複性工作。
針對這種情況，直接在controller端進行設定會簡單得多，只需要載入各個業務指令碼，並設定不同指令碼的併發數即可。對於本文中的案例，在controller中的設定方法如下所示。
該種方式的優缺點對比：
優點：
缺點：
效能測試場景設計之容量測試場景設計
目前僅限於容量測試場景設計。場景模型的設計過程其實就是根據預期目標tps和測試模型計算出每乙隻交易的併發使用者數和迭代間隔時間。選擇固定間隔時間方式，詳細方法請看7.3節中的pacing選項的說明，不同的預期目標tps將會得到不同的併發使用者數和間隔時間。首先，假定乙個總的目標tps，然後通過測試模...
效能測試場景
執行緒數 需要設定的併發使用者數 併發使用者數 受cpu的主頻 分配的記憶體大小 作業系統 允許開啟檔案數量 開放的埠數量 的影響，一台電腦，大概能支援 1500併發使用者數以內 http協議 ramp up時間 在多長時間內啟動所有的執行緒。注意 只是說明，在第n秒結束時，會產生m個併發使用者數，...
效能測試場景分析設計
效能測試工作多年，經歷大小專案上千個，說起效能測試可能一千個人眼中就有一千個哈姆雷特。有人會說效能測試就是搞個壓測工具壓下就行，有人會說效能測試是瓶頸定位，有人說效能測試是保障大促的測試，有人說效能測試是容量規劃等等。其實這都是片面的不完整的，效能測試是乙個複雜的系統工程，真正做一次完整的效能測試要...