實施步驟
將線上一臺節點offline,測試客戶端直連被測服務器
客戶端梯度增加并發(50),不斷增加并發直至超過設定的服務指標
優缺點
測試效果不受服務實際流量的限制,壓測時間靈活,適用于GET請求不會產生臟數據。業務指標可以通過測試客戶端直接獲取。
風險評估
風險低,首先機器offline不會影響到線上的正常請求;其次緩慢增加并發,不會造成服務崩潰的情況。
線上引流
線上引流,即將線上其它節點的請求復制到被測服務器上,推薦使用Tcpcopy工具。
測試數據:線上請求直接復制引流,無需準備數據
實施步驟
將線上一臺節點Off-line,按照Tcpcopy部署的方法部署client和server,為了便于指標的統計,通常將Tcpcopy部署在nginx所在服務器,被壓測服務器前需要增加一層nginx服務器。
將集群的其它節點流量復制到off-line節點上,可以通過tcpcopy –r參數逐步增加復制系數,不斷增加-r參數直至超過設定的服務指標
如果100%全部線上流量都不能壓測到off-line節點的瓶頸,再逐步放大引流系數
優缺點
請求真實,能夠放大流量,測試效果不受服務實際流量的限制,壓測時間靈活,但環境部
署稍微麻煩,對于PUT請求需要做一些業務處理,避免產生臟數據。
風險評估
風險低,首先機器offline不會影響到線上的正常請求,緩慢增加流量復制,不會造成服務崩潰的情況。
修改負載權重
對于一個集群,前面往往會有負載均衡服務器,以Nginx為例,通過修改Upstream模塊的負載均衡weight可以不斷增加集群某一節點的請求數,增加其訪問壓力。
測試數據:無需準備
實施步驟
緩慢增加nginx的負載均衡系數,使被測節點壓力不斷增加
直至超過設定的服務指標停止增加壓力
優缺點
完全真實的場景,壓測數據準確,但是依賴自身的流量,壓測時間不靈活,需在高峰期,對用戶體驗有一定影響,隨著一臺機器的負載增加響應時間會受到一定影響,會直接反饋給在線用戶。
風險評估
風險低,雖然在高峰期進行,但是只需要修改nginx配置再reload,對服務基本無影響,且每次都逐步增加weight,不會造成服務器崩潰的情況。
Step6 線上監控
線上監控不僅用于集群歷史數據的收集,計算集群的實際負荷的監控,還用于壓測過程中監控約束條件中的各種指標是否超限并停止壓測。根據集群的特點和之前性能測試經驗關注容量指標和約束條件的業務和資源指標。而這里的歷史數據,是需要長期的采集和整理。
小結
綜上所述,容量規劃主要圍繞著這么一個等式展開工作,紙上談來終覺淺,實踐出真知。希望能夠在接下來的實踐中成長和收獲。
原文轉自:http://www.uml.org.cn/Test/201406132.asp?artid=1801