即使是經驗豐富的 Java Web 開發人員，也會對開發門戶應用的巨大複雜度感到驚訝。最終用戶看到的簡單漂亮界面背後，是像 BEA WebLogic Portal 這樣的商業產品所提供的強大功能與複雜架構。當門戶應用進入生產階段，診斷性能問題將變得異常困難。
本文假設您已熟悉 WebLogic Portal 的功能與術語。
BEA WebLogic Portal 在一個完整的 Web 門戶開發與交付平台中，整合了統一的運行時框架、業務服務與生命週期管理技術，可針對數千終端用戶擴展並支援持續變更。
圖 1. WebLogic Portal 的層次化架構
門戶的基本構建塊是 Portlet，它是小型的門戶應用，在網頁中通常呈現為小方塊。Portlet 是可重用組件，提供對應用、基於 Web 的內容及其他資源的訪問，能訪問並顯示網頁、Web 服務、應用程式及聚合內容。
Portlet 獨立開發、部署、管理與顯示。管理員與終端用戶通過選擇和安排 Portlet 可創建個性化門戶頁，使網頁能針對個人、團隊、部門或組織量身打造。Portlet 依賴門戶基礎設施訪問用戶配置檔資訊、參與視窗與動作事件、與其他 Portlet 通信、訪問遠端內容、查找憑證與儲存持久數據。
由於 Portlet 也是 Servlet，它們共享類似的重入與性能關注點。單一 Portlet 實例（即 Portlet Java 類的單一實例）由所有請求者共享。因處理 Portlet 和 Servlet 的線程數有限，每個 Portlet 必須儘快完成工作，以優化整頁響應時間。
WebLogic Portal 控件樹代表門戶內的所有結構元素，充當構建新門戶頁所需的基礎設施。實例化門戶時，新控件樹在處理期間創建（或從緩存恢復）。門戶性能的一大障礙是控件數量：控件越多（頁、Portlet、按鈕等），控件樹越大，渲染所有組件所需時間越長。
圖 2. 一個門戶實例的典型控件樹
圖 2 顯示一個典型門戶生成的控件樹：由 Desktop 和 Shell 創建一個主 Book 和 6 個子 Book，每個子 Book 包含 2 個頁，每頁包含 2 個 Portlet，整個門戶至少包含 42 個控件。
控件樹構建完成且實例變量設置成功後，在門戶完全渲染前，此樹必須在整個生命週期中對每個控件依序運行。生命週期方法按順序調用：先調用每個控件的 init()，再調用 loadState() 等，調用順序由控件在門戶分類圖中的位置決定。每個控件的生命週期運行都需要開銷，若門戶有數千控件，時間可能呈指數級增長。因此，控件樹越大，對性能影響越嚴重。
門戶性能主要表現在用戶點擊對象向門戶 Servlet 發送請求時，實際渲染門戶及其所有組件所需的時間。
首要困難是如何監視和測量整體性能。內置管理功能無法充分覆蓋整個系統，特別是各個門戶組件（包括 Portlet 及 WebLogic Portal 容器運行的其他代碼）、數據庫連接、事務伺服器、主機系統及其他終端系統。
無論使用何種工具，該工具都需具備：
可能影響門戶性能與可用性的潛在因素有多個，以下討論應監視的內容與常見問題。
門戶是個性化 Web 應用，有必要像最終用戶那樣測量性能。通過測量事務響應時間，管理員可在問題影響用戶與業務前採取措施。
如前所述，控件樹代表所有結構元素。用戶介面設計中的所有元素都對應樹中的控件。需監視控件樹內的複雜處理及其與門戶「查看」和「控制」元素的交互。圖 3 顯示性能調優工具如何突顯控件樹中的性能問題。
圖 3. 凸顯控件樹中的性能瓶頸
應用程式、基於 JSP 的 Portlet、Web Services 或其他 J2EE 資源均可作為 Portlet 公開。若出現性能下降，支援人員應立即確定是哪個 Portlet 引起。Portlet 生命週期、處理回發數據與預渲染過程對性能監視尤為重要。
JSP backing 文件與 JSP 協作，實現表示邏輯與業務邏輯分離。Backing 文件總在 JSP 之後運行，包含大量定制渲染代碼（部分開發人員還會向終端系統呼叫獲取額外渲染數據）。性能不佳常預示定制渲染代碼可能有誤。
Java 頁面流完全由開發人員定義，速度減緩常由其作者診斷，不會對終端系統造成大影響。將 J2EE 標準頁面流與門戶控件樹處理架構關聯，可確定某頁面流與哪個 Desktop 相關，這也很有用。
希望本文能提供有用資訊，助您了解 WebLogic Portal 應用的性能問題。隨著企業門戶內容日益複雜與普及，管理其性能與可用性的挑戰也隨之增加。借助合適的工具與處理，基於門戶的應用仍可靠地實現預期業務價值。
