基於WebSphere Commerce的電子商務應用效能最佳化(1) 綜述

前言

隨著互連網的普及，越來越多的人選擇網上購物。各商家網上商店的競爭也是如火如荼。除了常見的打折 大促銷，還有限時搶購及讓人又愛又恨的秒殺活動。大量使用者幾乎同時訪問商店，對電子商務系統的硬體及軟 件效能都是極大的挑戰。一旦效能達不到要求，或者出現訪問中斷，損失的不僅是大量的營業額，還有使用者信 任度的下降，造成使用者流失。所以越來越多的企業在購買電子商務軟體時，不光注重其功能性，效能也成為被 認真考量的重要方面。

電子商務效能問題常常表現在大量使用者同時交易時，頁面響應速度慢，甚至發 生系統錯誤。還有就是在一個較短的時間段裡，即使系統負載沒有什麼變化，系統效能也發生明顯下降，從而 造成系統不能長期穩定運行。這些問題都會嚴重影響使用者交易體驗，並給企業帶來直接或間接重大經濟損失。

IBM WebSphere Commerce 基於 WebSphere Application Server， 是 IBM 為企業使用者提供的企業對 企業 (B2B) 或企業對客戶 (B2C) 的非常成熟的電子商務應用解決方案，是頂級企業的首選，被公認為是業界 領先的電子商務解決方案。它提供了下一代的解決方案，旨在應對企業的電子商務需求，並協助任何規模的企 業支援其客戶隨需應變地開展業務。WebSphere Commerce 提供一組緊密整合的軟體模組，協助企業客戶實現 快速的、高度自動化的跨渠道營銷和銷售流程。

近年來隨著中國電子商務市場的爆炸式增長， WebSphere Commerce 在中國的客戶越來越多，對本土實施團隊的要求也越來越高。在效能提升方面，與其在 出現效能問題之後再著手解決，不如在實施時期就做好高效能的設計。最佳化和提高電子商務系統的效能不僅需 要強大的理論知識，還需要有很強的實踐經驗。本系列就是以作者實際參與的 WebSphere Commerce 電子商務 應用為背景，在理論和實踐相結合的基礎上，詳細介紹在實際開發和維護工作中的具體使用經驗，以期協助開 發及服務人員在產品開發及上線初期就能做好效能最佳化。

WebSphere Commerce 支援多渠道 (multi- channel) 的訪問方式，其中 Web 是最主要的訪問渠道，所以本系列中的討論也以 Web 應用程式中的效能最佳化為 主。本文將不涉及高效能編程的內容，因為那將是一個更加龐大的知識系統。本文所提供的，是針對功能設計 完成之後，上線之前可以做的一些效能最佳化的原則和實踐。

基本概念性模型

WebSphere Commerce 不是一個孤立的系統，它是基於 WebSphere 上的一個複雜應用，如 錯誤：引用源未 找到 所示就是一個最基本的 WebSphere 應用概念性模型，其本身由 Web 服務器、應用伺服器和資料庫伺服器 組成，在系統的三層之間以及 Web 服務器與外網之間都設立了防火牆，提高系統的安全性。很多時候還會利 用內容分髮網絡（CDN）來緩衝靜態內容。 因此考慮系統的效能也絕不僅僅是考慮應用程式的效能，應該全面 考慮到用戶端，代理快取服務器，Web 服務器，WebSphere 應用伺服器和資料庫伺服器的效能。

圖 1. WebSphere 應用系統概念性模型

電子商務應用的效能關注點

對電子商務應用的效能來講，一般關注以下幾個典型方面：

頁面 / 用戶端的回應時間： 回應時間直接影響終端使用者的使用體驗，從而在很大程度上影響使用者忠誠度 。

伺服器的輸送量：常用的是系統每小時能處理的業務量。比如，最高每小時能接受的網站瀏覽次數，及一 個電子商務網站每小時能下多少個單等等。

最大並發使用者數： 正常運行狀態下，系統最多能承受多少使用者同時訪問且對使用者感受到的回應時間沒有顯 著影響。

長期啟動並執行穩定性：任何電子商務網站都不希望自己的系統越來越慢，甚至宕機，這對終端使用者會造成非 常不好的印象，從而也給業務帶來大的損失。應用服務系統是否能長期穩定運行除了跟伺服器的硬體有關係之 外，軟體本身也有很大的影響。

最大資料規模：當前硬體 / 軟體條件下，能保證正常訪問的最大容忍資料規模。

擴充能力：隨著業務量的增長，是否能夠靈活地通過增加硬體來增加系統的業務處理能力。

電子商務系統的效能最佳化，大多是以提升以上幾個效能關注點為目標而展開的。而針對每個目標，可以從 很多層面上入手。

簡單舉個例子，如果想要降低頁面的回應時間，首先需要瞭解回應時間受哪些因素 影響。瀏覽器的頁面請求通過網路傳輸發送到 CDN 和 Web 服務器進行解析。再由 Web 服務器發送到應用服 務器進行處理。如果動態快取命中，則直接返迴響應結果，如果不命中，則應用伺服器執行命令和計算。如果 有資料庫訪問需求，則發送到資料庫伺服器執行後返回。整個伺服器處理完畢後，響應開始經由網路向瀏覽器 端傳輸，瀏覽器對響應進行解析和繪製，最後顯示在瀏覽器上。以上是一個簡單的回應時間計算模型，如果是 在並發量比較大的情況下，會在某些步驟上存在資源爭奪和等待，回應時間的計算就會更加複雜。

圖 2. 頁面回應時間的組成