前言
隨著互聯網的普及，越來越多的人選擇網上購物。各商家網上商店的競爭也是如火如荼。除了常見的打折 大促銷，還有限時搶購及讓人又愛又恨的秒殺活動。大量用戶幾乎同時訪問商店，對電子商務系統的硬件及軟 件性能都是極大的挑戰。一旦性能達不到要求，或者出現訪問中斷，損失的不僅是大量的營業額，還有用戶信 任度的下降，造成用戶流失。所以越來越多的企業在購買電子商務軟件時，不光注重其功能性，性能也成為被 認真考量的重要方面。
電子商務性能問題常常表現在大量用戶同時交易時，頁面響應速度慢，甚至發 生系統錯誤。還有就是在一個較短的時間段裡，即使系統負載沒有什麼變化，系統性能也發生明顯下降，從而 造成系統不能長期穩定運行。這些問題都會嚴重影響用戶交易體驗，並給企業帶來直接或間接重大經濟損失。
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. 頁面響應時間的組成
從這個簡單的響應時間模型圖（圖 1-2）上我們可以看出，從浏覽器發出請求一直到頁面顯示，這期間 的每一步都需要時間，而減少每一步的時間都有助於降低整個頁面的響應時間。在進行優化的時候，可以從多 方面入手減少各個步驟的響應時間，例如：
從店鋪頁面設計著手，可以減少頁面顯示需要載入的內容；
從降低網絡傳輸量著手，可以將需要載入的內容進行壓縮傳輸；
從減少應用服務器運算量或者減少數據庫訪問著手，可以將返回內容存放在緩存上；
從提高應用服務器或數據庫訪問效率入手，可以將各級服務器進行調優。
上線前的性能優化原則
在系統上線之前，實施人員需要在目前應用功能已經就緒的基礎上，再做進一步的配置和優化以提升性能 。這方面的性能優化需要遵循一些原則，例如：
減少頁面本身的顯示開銷。隨著 Web2.0 技術的流行，越來越多的用戶交互被放在浏覽器端執行，客戶端 的計算開銷加大。一些技術可以在保證效果的同時減少此類開銷。
無需等到所有響應返回才顯示頁面。將用戶接下來需要浏覽或操作的響應部分先返回並及時展示給客戶， 可以有效提高用戶使用體驗。
減少載入頁面需要傳輸的數據量。僅傳輸必需的數據。
將需要傳輸的數據進行壓縮。
減少顯示頁面需要向後台服務器發送請求的次數。
將靜態內容盡量放在離客戶端更近的地方。比如，利用內容分發網絡存儲靜態內容。
充分利用緩存。包括正確使用代理服務器，Web 服務器，應用服務器等各級緩存。
將各級服務器按照實際系統的需要做參數調整。遵循合適的調優原則。一次只調一個或一組參數，以防止 不同參數之間相互影響。每次調優後進行測試以確定調優效果。
為維護性操作設置合適的日程表。減少維護性操作對用戶體驗的影響。確保維護性操作不會引起頁面響應 時間的顯著變化。
制定合理有序的優化計劃和步驟。避免無目的的更改。
充分的測試以保證調優效果，以及確保調優沒有對功能造成影響。
電子商務應用的優化實踐經驗
基於以上這些原則，本系列文章將分多個部分，按照從前端至後端的順序，從不同的方面詳細介紹基於 WebSphere Commerce 的電子商務應用的優化實踐經驗。
店鋪頁面設計的性能優化
首先，從最前端的店鋪頁面設計開始。店鋪頁面設計決定著頁面顯示需要發送什麼樣的請求以及得到那些 響應，從而決定著後面各步的時間。在業務需求已經確定的情況下，一些最佳實踐可以使用戶在不犧牲頁面功 能和效果的情況下減少浏覽器解析 / 構建渲染樹 / 繪制所需要的時間（圖 1-2 中的時間 T1）和減少一個頁 面顯示所需要的網絡傳輸次數（從而減少圖中 T2 的總時間），從而有效提升頁面的響應速度和用戶體驗。本 系列的第 2 部分，將詳細介紹想要構建具有高性能的 WebSphere Commerce 的電子商務網站，在店鋪頁面設 計方面從開發者的角度應該注意些什麼。這些最佳實踐來自為中國的電子商務客戶設計店鋪頁面的經驗 , 包 括：
異步處理
延遲加載
使用 CSS sprites 處理網頁圖片
介紹網頁設計中性能監視常用的工具
對網絡傳輸數據進行“瘦身”
頁面請求和響應確定的前提下，響應通過網絡傳輸的時間長短，就影響了頁面顯示的時間。這些網絡傳輸 ，最大的一部分來自將響應從網絡服務器傳輸至客戶端浏覽器的時間（圖 1-2 中的 T2），因為這段時間大多 是存在於廣域網的傳輸，帶寬往往不可預計。還有一部分來自於多節點服務器環境中不同節點之間的內網傳輸 ，比如圖 1-2 中的應用服務器和 Web 服務器之間的傳輸時間 T3 和數據庫服務器與應用服務器之間的傳輸時 間 T4。雖然在內網環境中這段傳輸時間相對較小，但當並發訪問量很大時，這些網絡傳輸也有可能成為性能 尤其是吞吐率的瓶頸。相對來講，網絡上傳輸的數據量越小，對快速響應越有利。因此，要對網絡流量進行“ 瘦身”。本系列的第 3 部分，網絡流量瘦身建議，將介紹采用哪些措施可以有效減少用戶訪問基於 WebSphere Commerce 的電子商務網站時網絡上的數據流量。這將有效提升頁面的訪問速度，以及減少並發訪 問量較高時網絡成為性能瓶頸的可能性。這些最佳實踐主要包括在不改動內容和功能的前提下，如何：
減小 JSP 大小
減小 javascript/css 大小
縮小圖片尺寸
將 Web 服務器設置為壓縮傳輸
減少應用服務器和 Web 服務器間的數據傳輸
設置浏覽器端緩存
充分利用各類緩存
WebSphere Commerce 推薦盡量利用各級緩存。舉個例子，如圖 1-2，一般來說，緩存不命中情況下的響應 時間（T3+T4+T5+T6）會遠大於緩存命中情況下的響應時間（T7+T8）。因此充分利用緩存能在很大程度上降低 應用服務器和數據庫的負載，以及提升響應速度。本系列的第 4 部分，緩存設計建議，將在帶領讀者了解了 WebSphere Commerce 的高速緩存策略和典型架構之後，指導讀者如何設計自己的緩存，包括：
如何寫一段網頁片段緩存
如何寫一段命令緩存，以及了解命令緩存的運行模式
了解數據緩存
緩存失效機制以及如何定義緩存失效
如何啟動磁盤緩存
如何與 WebSphere Extream Scal 集成
該部分還會介紹緩存設計的常見問題的解決方法及一些最佳實踐：
為什麼緩存更新後沒有生效
為什麼緩存後看到的頁面內容有重復
設置的緩存對象數目達不到預期效果
緩存引起的內存異常
如何做緩存預加載
DRS （Data Replication Service）緩存數據同步機制
如何提高緩存覆蓋率及命中率等
無處不在的參數調優
任何系統發布和上線前都要進行參數調優。參數調優涉及系統的各個層面，目的是將整個線上系統調整到 一個適合硬件軟件條件且滿足業務量需求的相對最優的狀態。由於不同服務器，不同參數之間可能會相互影響 甚至抵消調優效果，參數調優不能隨心所欲的調整，需要遵循一定的原則。本系列的第 5 部分，參數調優建 議，將告訴讀者基於 WebSphere Commerce 的電子商務系統的調優最佳實踐，包括
應該在什麼時機進行參數調優
應該遵循什麼樣的調優原則
常用的參數調優模型：漏斗模型
針對重點參數給出說明和調優建議
系統管理員應該注意些什麼
基於 WebSphere Commerce 的電子商務網站上線之後，系統管理員需要持續對系統進行性能監控和性能維 護。實時的監控和維護對於及時發現系統的性能問題十分重要，可以避免更大的損失。但同時，監控和維護性 操作也會占用系統資源，同時一些對系統的更新和調整操作，尤其是對於數據庫的維護和表更新可能會影響前 台用戶訪問的速度。本系列第 6 部分會針對如何執行這些監控和維護性操作給出建議。
監控和維護包 括很多方面，比如
查看動態緩存的命中率，淘汰率是否健康，是否需要調整
隨著數據增刪查改等操作而導致磁盤空間碎片增加和數據分布變化情況，是否需要執行碎片檢查整理和數 據分布統計信息更新
清除數據庫積累的大量歷史記錄，諸如失效的促銷和市場活動，過期的用戶會話信息和上下文信息等
服務器 Java 虛擬機的內存使用情況等
在執行一些更新或維護操作，比如 StageProp，DBClean，DataLoad 等操作時，應該有哪些注意事項，避 免對前台用戶的訪問性能造成影響。
該部分還會介紹要實現各類監控需要借助哪些系統監控工具。
針對特色功能的調優實例
WebSphere Commerce 新版本提供許多特色的功能，比如基於開源搜索引擎 Solr 的搜索功能。作為一個性 能優化的實例，本系列第 7 部分將介紹如何優化能夠將 WebSphere Commerce 新版本上的特色搜索功能的性 能發揮到相對最優。這些內容包括
基於 Solr 的搜索生產環境規劃與部署建議
Solr 服務器與 WebSphere Commerce 服務器所使用的 Web 服務器參數優化
Solr 服務器運行時 Java 虛擬機參數優化
WebSphere Commerce 端數據預處理
構建基於 Solr 的搜索索引
WebSphere Commerce 針對 Solr 的運行時定制化
Search Service 的優化及合理使用
針對 Solr 搜索定制 WebSphere Commerce 數據緩存
基於 Solr 的搜索框架的其他新功能的優化
結束語
電子商務系統的性能優化，設計的方面多而雜。本系列的目的就是幫助讀者系統地了解性能優化的各方面 並且有目的的制定優化計劃，從而使優化過程更順暢，效果更顯著。除現有的幾個部分之外，後面還會有新的 WebSphere Commerce 的性能優化方面的最佳實踐陸續添加到本系列中。下一部分，將從店鋪頁面設計建議開 始，帶領讀者進入詳細的討論。
