基於WebSphere Commerce的電子商務應用效能最佳化(5) 參數最佳化建議

參數最佳化建議

WebSphere Commerce 是基於 WebSphere 應用程式伺服器開發的大型電子商務應用程式。在初次成功安裝 WebSphere Commerce 應用程式之後，安裝程式已經對伺服器上的關鍵參數進行了初始化調整。這組預設值是 WebSphere Commerce 測試團隊經過反覆測試總結出來的一組初始化的參數值。建議維護人員以這組預設值作 為初始值進行測試，比較測試結果與期望值的差距，從而有計劃的對應用程式伺服器的部分參數進行最佳化。如 果您正在維護的生產環境運行正常，系統效能可以達到預期要求，我們不建議您對現有的環境進行最佳化。

其實調優本身並沒有一個最優解。系統是否能夠滿足客戶的需求並儘可能多的發現和解決系統存在的 隱患，很大程度上取決於維護人員的經驗。生產環境不允許做實驗，所以在測試環境上進行完整充分的測試是 非常必要的。另外生產環境和測試環境規模存在差異，在設定參數時需要考慮參數的適用性。

圖 1. 效能調優的生命週期

WebSphere Commerce 參數最佳化原理

WebSphere Commerce 是一個資料庫密集型的應用程式，大多數 JSP 和 Servlet 請求都需要訪問後端 的資料庫，同時系統後台還運行著多個任務。所以它並不完全滿足漏鬥模型的假設條件。在參數調優過程中可 以借鑒漏鬥模型的原理，但是要針對特定部分做一些調整。

圖 2. 資料庫密集型應用程式的 參數調優模型

在某一特定的測試環境中，假設有 200 個並發使用者同時到達 Web 服務器，Web 服務器的並發處理能力為 75，應用程式伺服器 Web 容器串連池 的值為 50，之後請求從 Web 容器到資料庫連接池的大小設定為 61，對於 WebSphere Commerce 這裡不僅需 要考慮 Web 容器處理的請求數，同時也要考慮預留一部分資源滿足後台工作的需要，其中包括：1. 後台計劃 工作 2. 管理員登入管理主控台操作 3. 處理資料拷貝（data prop）。

* 資料庫連接池的大小 = Web 服務器轉寄的客戶請求 + 後台計劃工作 (Scheduler Job) + 管理員串連後台資料庫所產生的資料庫連接請求 + 處理 data prop 的請求所需要的串連數

上面的例子說明，Web 容器和資料庫連接池的大小之間的比 例要根據具體應用程式的需求進行調整，不能盲目應用漏鬥模型。

參數調優的基本原則

在決定進行參數調優之前，首先需要制定一份詳細的調優方案，明確調優的目標，然後根據 系統監控結果，找出可能影響系統效能的方面，嘗試在系統上每次只調整一個參數，監控系統效能指標的變化 情況，根據系統監控的結果，再做進一步調節的計劃。參數調優中最重要的原則是：每次最好只調整一個參數 。

圖 3. 參數調優流程圖