**：阿里雲效能測試頁面
需要臨時擴容他們的機器來支援100w的qps，每秒100w的請求，聽起來還是挺恐怖的。什麼概念呢，2013 年雙12的大秒系統的峰值qps也就在42萬多。從這樣的資料來看，這個客戶的需求高的離譜。但是既然使用者有這個需求，我們還是需要滿足客戶的期望。
遇到問題主要有：
遇到的挑戰主要有：
經過多次會議，確定解決方案是，採用阿里雲環境自動化運維及彈性擴容來搭建環境，壓測工具採用分布式壓測。
通過評估機器數量如下：
整個團隊包括客戶、slb和ecs機器維護人員、環境部署人員以及效能測試團隊充分密切配合。
qps：100萬，穩定執行1分鐘左右。
秒殺活動，乙個比較複雜的帶header, body, cookie 的http 請求。
qps下降的原因經過各技術專家診斷一致認為是slb丟包導致，slb壓力已到極限，因此建議需要配置3臺slb，每台slb掛100臺ecs，才有可能滿足100萬qps 。經過與客戶會討，峰值71.5萬qps，穩定執行4分鐘50萬qps，能滿足目前現在的業務需求。如果需要支援100萬qps，需要擴容slb，至少是3臺slb以上。
7.1.1 穩定性
在測試過程中，效能測試經受住了大規模壓力的考驗，並且從未出現過異常問題，由此可知，效能測試產品非常穩定。
7.1.2 百萬級qps支援
在測試的過程中，效能測試能支撐百萬級qps的壓力發起，這是目前其他壓測工具所不能支援的。
7.1.3 資源消耗少
雖然效能測試壓測機申請了300臺ecs機器，但在測試過程中，消耗的機器資源非常少，cpu利用率不到0.1%，並且每台機器負載均衡，實際上100臺ecs就足夠了。
在調研階段，效能測試團隊就大規模壓力發起進行了充分的調研，並且通過測試驗證單台機器能發起的壓力以及彈性擴容，預估出需要的機器數量，才能保證專案的順利進行。另外阿里雲批量自動化環境搭建節省了環境的部署時間，在1天內完成所有工作。
這次大規模壓力壓測在5天內順利完成，離不開整個團隊所有人員密切配合，重點關注，才能讓如此大的專案在短時間內成功實施。因此團隊合作在專案實施的過程中有起著舉足輕重的作用。
jmeter分布式壓測
在本機不足以支撐壓力測試時，可進行分布式壓測，使用其他的一台或多台機器進行壓測。本機為主控機，其他的機器 如他人電腦 或公司伺服器 為壓力機。jmeter分布式壓測的操作方法 1 其他的壓力機啟動jmeter server，如果本機也要做壓力機，則本機也需要啟動jmeter server。2 在主控...
Jmeter分布式壓測配置
有時候需要大併發的情況，不僅取決於伺服器配置，負載機配置也有要求，包括jmeter配置 場景一 負載機併發過高，cpu100 需要考慮分布式 場景二 負載機併發過高，jmeter滋生記憶體溢位，jmeter報錯 unable to create new native thread 關於場景二說到的問...
jmeter 分布式壓測（windows）
單台壓測機通常會遇到客戶端瓶頸，受制於客戶機的效能。可能由於網路頻寬，cpu，記憶體的限制不能給到伺服器足夠的壓力，這個時候你就需要用到分布式方案來解決客戶機的瓶頸，壓測的結果也會更加接近於真實情況。jmeter 分布式壓測原理 分布式壓測分為兩塊 控制器 controller 和 agent 1....