即使是經驗豐富的 Java Web開發人員也會驚訝於開發門戶這一如此巨大的飛躍。最終用戶看到的那個簡單漂亮的界面的背後是像BEA WebLogic Portal 這樣的商業產品提供的強大功能和復雜性。當門戶應用程序處於生產階段時，診斷性能問題就會顯得格外的困難。
本文假設您對WebLogic Portal的功能和術語已經十分熟悉。
一個公司的門戶能讓公司更有效地利用其技術和人力資產，而同時又能為其員工、合作伙伴和客戶提供一流的Web體驗。由於這個原因，門戶應用程序現在對業務來說十分關鍵，並且要能提供可靠的性能和可擴展性。BEA WebLogic Portal 是一種領先的基於Java EE 的門戶服務器，可提供部署和運行門戶應用程序的健壯的解決方案。
WebLogic Portal 架構
BEA WebLogic Portal 在一個完整的Web門戶開發和交付平台中綜合了統一的運行時框架、業務服務和生命周期管理技術。它可針對數千最終用戶擴展並支持連續更改。
圖1 顯示了 WebLogic Portal 架構。在門戶被實例化時，它會生成門戶資源的分類或層次，即所謂的WebLogic Portal 控件樹。控件樹包括desktop、book和portlet。如您所見，控件樹對於理解門戶應用程序中的性能問題至關重要。
圖1. WebLogic Portal的層次化架構
門戶的基本構建塊是portlet，portlet是小的門戶應用程序，在Web頁內通常描述為小盒子。它們是可重用組件，可提供到應用程序、基於Web的內容和其他資源的訪問，並且可以訪問和顯示Web頁、Web服務、應用程序和連鎖內容提要。
Portlet 相互獨立開發、部署、管理和顯示。管理員和最終用戶通過選擇和安排portlet可以創建個性化的門戶頁，這樣一來， Web 頁就可針對個人、團隊、部門或組織量身打造。Portlet 依賴於門戶基礎架構來訪問用戶配置文件信息、參與窗口和動作事件、與其他portlet 通信、訪問遠端內容、查找憑證和存儲永久數據。
由於portlet 也是servlet，所以它們共享類似的重入和性能關注點。單一的 portlet 實例(即portlet 的 Java 類的單一實例)由所有請求者共享。由於處理portlet和 servlet 的線程數量有限，所以每個 portlet 要能盡快地完成其作業，以便整個頁的響應時間能夠得到優化，這一點非常重要。
理解控件樹
WebLogic Portal 控件樹代表門戶內的所有結構元素，可充當構建新門戶頁所需的基礎架構。在實例化門戶時，新控件樹在控件樹處理期間創建(或從緩存清除，如果控件樹已經存在)。門戶性能的一個巨大阻礙就是門戶內的控件的數量。門戶控件越多(頁、portlet、按鈕等)，控件樹就越大，呈現所有組件所需的時間越長。
圖 2 顯示了一個為典型的門戶所生成的控件樹。由desktop 和 shell 創建一個主 book 和6個子book，而每個子book各包含2個頁。每個頁包含2個 portlet。所以，整個門戶共包含至少42個控件。
圖2.一個門戶實例的典型控件樹
一旦控件樹構建完畢且實例變量也設置成功，在門戶被完全呈現之前，此樹必須在整個生命周期針對每個控件運行。生命周期方法被順序調用。即，調用每個控件的 init() 方法，然後是每個控件的loadState() 方法，等等，調用的順序由每個控件在門戶分類圖中的位置決定。
在生命周期運行每個控件需要一些開銷處理時間，如果門戶有數千個控件，這一時間就有可能會按指數級增長。因此可見，門戶控件樹越大，對性能的影響就越嚴重。
在 WebLogic Portal 中監視性能
門戶的性能主要表現在當用戶單擊對象向門戶servlet發送請求時，實際呈現該門戶及其所有組成部分所需的時間。
面臨的第一個困難是如何監視和測量門戶的整體性能。內置的管理功能並不能充分滿足整個系統，特別是各個門戶組件(包括portlet 以及由WebLogic Portal容器運行的其他代碼)、到任意或所有數據庫的連接、事務服務器、主機系統和其他終端系統。
無論使用的是何種工具，該工具都需要能：
監視跨整個工作流發生的以及在各個過程中發生的那些復雜的動態交互。
能簡潔直觀地顯示結果數據，以突出所存在的問題(以及在門戶工作流中發生的位置)並讓管理員能快速向下鑽取(如果需要，可鑽取至各個portlet 或事務)以發現問題的根源。
總結整體性能以及關鍵的門戶工作流領域(門戶servlet、控件樹處理、JSP backing文件、Java頁面流、portlet、到後端系統的連接以及門戶服務)中的性能。
應該監視什麼以及常見問題
可能影響門戶性能和可用性的潛在因素有幾個。以下內容討論了應該監視什麼以及常見的問題有哪些。
門戶請求響應時間
由於門戶是個性化的Web應用程序，所以很有必要像最終用戶所經歷的那樣測量門戶的性能。通過測量事務響應時間，門戶管理員就能在問題影響用戶和業務之前提前采取相應措施。
控件樹處理
前面提到過，WebLogic Portal 控件樹代表門戶內的所有結構元素，可充當構建新門戶頁所需的基礎架構。在用戶-接口設計中的所有元素都會對應於樹中的控件。所以要監視在控件樹內發生的復雜的處理以及它與門戶的“查看”和“控制”元素間的交互。圖 3 顯示了性能調優工具是如何突現控件樹中的性能問題的。
圖3. 凸顯控件樹中的性能瓶頸
Portlet
應用程序、基於 JSP 的 portlet、Web Services 或其他可用的 J2EE 資源均可作為portlet 公開。如果出現了性能下降，應用程序支持人員就應該能立即確定引起性能下降的是哪個portlet。在portlet 生命周期，處理回發數據和預呈現的那些過程對於性能監視尤其重要。
Portal Framework 服務
JSP backing 文件與 JSP 協同工作，允許表示邏輯與業務邏輯分離。Backing 文件總是在JSP之後運行，它包含大量的定制呈現代碼(另外，一些開發人員還會向終端系統進行callout 來獲取額外的呈現數據)。不佳的性能常常預示著定制呈現代碼可能不正確。
在 Java 頁面流，頁面流本身完全由開發人員定義。速度上的減慢常常能由其作者診斷出來，並不會對終端系統造成很大的影響。將 J2EE 標准頁面流與門戶控件樹處理架構關聯起來還可確定某個頁面流與哪個desktop 相關，這一點也非常有用。
WebLogic Portal 服務
Entitlement 系統為各個門戶資源提供了基於角色的授權。Entitlement 被門戶的所有方面大量使用，所以任何的減慢都會影響到整個系統。通常，延時的響應和遲滯的線程大多都是由支持Entitlement的後端系統，比如LDAP，內存在的問題引起的。此外，對太多的對象進行細粒度的授權也會加大Entitlement 系統的開銷。
Personalization 服務通過advislet 實現，用來修改在門戶首選項中顯示的信息。Advislet 可使用多種機制，比如內部規則引擎、顯式個性化，甚至事件。過度使用Personalization 系統也常常會引起性能問題。
User Profile 存儲庫包含額外的用戶信息，比如聯系信息。通常，延時的響應和遲滯的線程大多都是由於後端系統存在的問題，比如用於支持用戶配置文件的數據庫，引起的。
Content Management API 與很多可用的商業內容管理系統(比如Documentum)接口。如果這裡產生了遲滯的線程，首先需要檢查的就是後端內容系統是否工作正常。
結束語
我們非常希望本文能夠提供有用的信息，以使您對由WebLogic Portal 應用程序的性能問題有所了解。隨著企業門戶所提供的內容的日益復雜和普及，管理其性能和可用性的挑戰性也隨之增加。借助合適的工具和處理，基於門戶的應用程序還是可以信賴的，能夠實現它們所預期的業務價值。
