丨決定容量場景成敗的關鍵因素有哪些

首先是目標，你要記住，容量場景一定要有目標如果量場有目那就結束時間點的。因此，我在寫 性能方案那一講時，特別提到了性能項目的目標。請你注意，在很多性能項目中，由于給出的容量場景目標不夠具體，或者是存在“只給出大S給業(yè)的求，容量的執(zhí)如無水，哪流往哪流，這肯定是不行的。00S”就是我們的總體指標，也就是容量場景的目標。而它對應的業(yè)務模型就應該是這個樣子的（下表為示例）：關于業(yè)務模型，我要跟你明確一下：我們在執(zhí)行容量場景時，要包括所有的并發(fā)業(yè)務（可以用接口拼出業(yè)務），在一個業(yè)務系統中，只有包括了所有的業(yè)務接口，才是真正的容并且，業(yè)務模型的比例要符合生產中的真實業(yè)務場景（具體請 第5講中的業(yè)務型和性能指標部分），峰值，并且還要覆蓋生產環(huán)境中的最大資源使用率峰值。我們在 第6講，要想抽取出符合真實業(yè)務場景的業(yè)務模型，正常的邏輯應該：先把生產環(huán)境中的業(yè)務做統計，并給出相應的業(yè)務比例，然后把業(yè)務比例在壓力工具中設置好，結果中的比例和統計出的業(yè)務比例一致。如果市場上沒有同類型的業(yè)務系統，也沒有可借鑒的數據，你可以嘗試一下我的做現在有一些生產流量的工具，它們的目標之一就是為了解決業(yè)務模型和生產一的問題，這是行業(yè)正在做的努力。不管我們用什么樣的方式，流量也好，業(yè)務模型計也好，都是合理的思路和。除此之外，當業(yè)務模型具體要配置到容量場景中時，還有一個問題是經常被問到的，那就是怎么用壓力工具實現具體的業(yè)務比例。關于這一點，你可以在第5講中得到答案如果你是用JMeter的話，可以使用ThroughputController來控制業(yè)務比例。當然，如關于業(yè)務模型能不能真正到容量場景中，還有一個動作至關重要，那就是執(zhí)行結束之后，你要把場景的結果和業(yè)務模型中的比例做環(huán)比同時，我們要考慮好容量場景中需要用到的數據量級。請參考第5講中的數據準備部分和第容量場景的參數化數據，一定要和生產中實際用戶的使用規(guī)則與數據量級保持一致鋪底數據一定要通過計算做相應的縮減，最好能和生產一致我們在第 講中已經詳細描述過全局和定向設計策略，這里我就不再重復了。首先，全局的所有計數器都要和項目級的性能分析決策樹對應于點，理起來很容易，但是不一定能輕易做到，因為每個工具都不夠全面，或者說很多工具的設計理念都各不相同。如果你所在的企業(yè)，系統是固定的，并且在做不斷的演進，那你最好能有自己的平臺設計理念。我們在第9講中也說到全局來自于架構分析，有了這個邏輯，你才能明白為什么性能和架構的相關性會這么大。在性能分析的具體操作過程中，你會發(fā)現，我們對計數器的理解程度和方向的判斷有著絕對的關系，比如說，當我們看到usuyusl到底是被誰調用的。我們再來看容量場景中的壓力策略。同樣是在第5講中，我強調了在性能場景的壓力可能有人會問，連續(xù)比較容量理解，那遞增是怎樣一個遞增法呢？這一點，我們在 基準場景中就有過描述，我也做過相應的壓力線程的計算，在這里我就不重復了。如果你也有類似的疑問，建議你再詳細回顧一下。我要提醒你的是，容量場景中的壓力線程可以沒有明顯的階梯，但是一定要實現遞增有人會說，為了模擬有多個用戶同時操作，用集合點不是挺合理的嗎？要問一個問題了：壓力工具的集合點是在哪里集合的？是在服務端集合的嗎？顯然不是吧，集合點只能在壓力工具這一端集合。而集合的請求經過了CPU20在第 講中，我們提到過啟動準則。在很多企業(yè)中，這個啟動準則只是文檔中的條目你想想，如果滿足不了啟動條件（比如未定版、功能未開發(fā)完成、架構和生產不一致、環(huán)境差異性等），就會導致邊測邊改，這是非常耗時間的，并且要重復做很多次。這樣不僅增加了性能項目的成本，還降低了性能人員的價值，同時也體現出項目管理非常的問因此，在這節(jié)課中，我把容量場景中重要的地方再給你捊了一遍，希望你能對容量場景重視起來。另外，給你一個小提醒，即便是所有的基準場景都執(zhí)行得很好，容量場景也不是必然會順暢，所以你要做好心理準備。 不得售賣。頁面已增加