簡介

　　即使是經(jīng)驗(yàn)豐富的 Java Web 開發(fā)人員也會(huì)驚訝于開發(fā)門戶這一如此巨大的飛躍。最終用戶看到的那個(gè)簡單漂亮的界面的背后是像BEA WebLogic Portal 這樣的商業(yè)產(chǎn)品提供的強(qiáng)大功能和復(fù)雜性。當(dāng)門戶應(yīng)用程序處于生產(chǎn)階段時(shí)，診斷性能問題就會(huì)顯得格外的困難。

　　本文討論了 WebLogic Portal 在性能管理方面存在的一些挑戰(zhàn)，并為在門戶應(yīng)用程序內(nèi)進(jìn)行性能瓶頸調(diào)優(yōu)提供了一個(gè)很好的起點(diǎn)。本文假設(shè)您對(duì)WebLogic Portal的功能和術(shù)語已經(jīng)十分熟悉。

　　一個(gè)公司的門戶能讓公司更有效地利用其技術(shù)和人力資產(chǎn)，而同時(shí)又能為其員工、合作伙伴和客戶提供一流的Web體驗(yàn)。由于這個(gè)原因，門戶應(yīng)用程序現(xiàn)在對(duì)業(yè)務(wù)來說十分關(guān)鍵，并且要能提供可靠的性能和可擴(kuò)展性。BEA WebLogic Portal 是一種領(lǐng)先的基于Java EE 的門戶服務(wù)器，可提供部署和運(yùn)行門戶應(yīng)用程序的健壯的解決方案。

WebLogic Portal 架構(gòu)

　　BEA WebLogic Portal 在一個(gè)完整的Web門戶開發(fā)和交付平臺(tái)中綜合了統(tǒng)一的運(yùn)行時(shí)框架、業(yè)務(wù)服務(wù)和生命周期管理技術(shù)。它可針對(duì)數(shù)千最終用戶擴(kuò)展并支持連續(xù)更改。

　　圖1 顯示了 WebLogic Portal 架構(gòu)。在門戶被實(shí)例化時(shí)，它會(huì)生成門戶資源的分類或?qū)哟危此^的WebLogic Portal 控件樹。控件樹包括desktop、book和portlet。如您所見，控件樹對(duì)于理解門戶應(yīng)用程序中的性能問題至關(guān)重要。

　　圖1. WebLogic Portal的層次化架構(gòu)

　　門戶的基本構(gòu)建塊是portlet，portlet是小的門戶應(yīng)用程序，在Web頁內(nèi)通常描述為小盒子。它們是可重用組件，可提供到應(yīng)用程序、基于Web的內(nèi)容和其他資源的訪問，并且可以訪問和顯示W(wǎng)eb頁、Web服務(wù)、應(yīng)用程序和連鎖內(nèi)容提要。

　　Portlet 相互獨(dú)立開發(fā)、部署、管理和顯示。管理員和最終用戶通過選擇和安排portlet可以創(chuàng)建個(gè)性化的門戶頁，這樣一來， Web 頁就可針對(duì)個(gè)人、團(tuán)隊(duì)、部門或組織量身打造。Portlet 依賴于門戶基礎(chǔ)架構(gòu)來訪問用戶配置文件信息、參與窗口和動(dòng)作事件、與其他portlet 通信、訪問遠(yuǎn)端內(nèi)容、查找憑證和存儲(chǔ)永久數(shù)據(jù)。

　　由于portlet 也是servlet，所以它們共享類似的重入和性能關(guān)注點(diǎn)。單一的 portlet 實(shí)例（即portlet 的 Java 類的單一實(shí)例）由所有請(qǐng)求者共享。由于處理portlet和 servlet 的線程數(shù)量有限，所以每個(gè) portlet 要能盡快地完成其作業(yè)，以便整個(gè)頁的響應(yīng)時(shí)間能夠得到優(yōu)化，這一點(diǎn)非常重要。

理解控件樹

　　WebLogic Portal 控件樹代表門戶內(nèi)的所有結(jié)構(gòu)元素，可充當(dāng)構(gòu)建新門戶頁所需的基礎(chǔ)架構(gòu)。在實(shí)例化門戶時(shí)，新控件樹在控件樹處理期間創(chuàng)建（或從緩存清除，如果控件樹已經(jīng)存在）。門戶性能的一個(gè)巨大阻礙就是門戶內(nèi)的控件的數(shù)量。門戶控件越多（頁、portlet、按鈕等），控件樹就越大，呈現(xiàn)所有組件所需的時(shí)間越長。

　　圖 2 顯示了一個(gè)為典型的門戶所生成的控件樹。由desktop 和 shell 創(chuàng)建一個(gè)主 book 和6個(gè)子book，而每個(gè)子book各包含2個(gè)頁。每個(gè)頁包含2個(gè) portlet。所以，整個(gè)門戶共包含至少42個(gè)控件。

　　圖2.一個(gè)門戶實(shí)例的典型控件樹

　　一旦控件樹構(gòu)建完畢且實(shí)例變量也設(shè)置成功，在門戶被完全呈現(xiàn)之前，此樹必須在整個(gè)生命周期針對(duì)每個(gè)控件運(yùn)行。生命周期方法被順序調(diào)用。即，調(diào)用每個(gè)控件的 init() 方法，然后是每個(gè)控件的loadState() 方法，等等，調(diào)用的順序由每個(gè)控件在門戶分類圖中的位置決定。

　　在生命周期運(yùn)行每個(gè)控件需要一些開銷處理時(shí)間，如果門戶有數(shù)千個(gè)控件，這一時(shí)間就有可能會(huì)按指數(shù)級(jí)增長。因此可見，門戶控件樹越大，對(duì)性能的影響就越嚴(yán)重。

在 WebLogic Portal 中監(jiān)視性能

　　門戶的性能主要表現(xiàn)在當(dāng)用戶單擊對(duì)象向門戶servlet發(fā)送請(qǐng)求時(shí)，實(shí)際呈現(xiàn)該門戶及其所有組成部分所需的時(shí)間。

　　面臨的第一個(gè)困難是如何監(jiān)視和測(cè)量門戶的整體性能。內(nèi)置的管理功能并不能充分滿足整個(gè)系統(tǒng)，特別是各個(gè)門戶組件（包括portlet 以及由WebLogic Portal容器運(yùn)行的其他代碼）、到任意或所有數(shù)據(jù)庫的連接、事務(wù)服務(wù)器、主機(jī)系統(tǒng)和其他終端系統(tǒng)。

　　無論使用的是何種工具，該工具都需要能：

• 監(jiān)視跨整個(gè)工作流發(fā)生的以及在各個(gè)過程中發(fā)生的那些復(fù)雜的動(dòng)態(tài)交互。
• 能簡潔直觀地顯示結(jié)果數(shù)據(jù)，以突出所存在的問題（以及在門戶工作流中發(fā)生的位置）并讓管理員能快速向下鉆取（如果需要，可鉆取至各個(gè)portlet 或事務(wù)）以發(fā)現(xiàn)問題的根源。
• 總結(jié)整體性能以及關(guān)鍵的門戶工作流領(lǐng)域（門戶servlet、控件樹處理、JSP backing文件、Java頁面流、portlet、到后端系統(tǒng)的連接以及門戶服務(wù)）中的性能。

應(yīng)該監(jiān)視什么以及常見問題

　　可能影響門戶性能和可用性的潛在因素有幾個(gè)。以下內(nèi)容討論了應(yīng)該監(jiān)視什么以及常見的問題有哪些。

門戶請(qǐng)求響應(yīng)時(shí)間

　　由于門戶是個(gè)性化的Web應(yīng)用程序，所以很有必要像最終用戶所經(jīng)歷的那樣測(cè)量門戶的性能。通過測(cè)量事務(wù)響應(yīng)時(shí)間，門戶管理員就能在問題影響用戶和業(yè)務(wù)之前提前采取相應(yīng)措施。

控件樹處理

　　前面提到過，WebLogic Portal 控件樹代表門戶內(nèi)的所有結(jié)構(gòu)元素，可充當(dāng)構(gòu)建新門戶頁所需的基礎(chǔ)架構(gòu)。在用戶-接口設(shè)計(jì)中的所有元素都會(huì)對(duì)應(yīng)于樹中的控件。所以要監(jiān)視在控件樹內(nèi)發(fā)生的復(fù)雜的處理以及它與門戶的“查看”和“控制”元素間的交互。圖 3 顯示了性能調(diào)優(yōu)工具是如何突現(xiàn)控件樹中的性能問題的。

　　圖3. 凸顯控件樹中的性能瓶頸

Portlet

　　應(yīng)用程序、基于 JSP 的 portlet、Web Services 或其他可用的 J2EE 資源均可作為portlet 公開。如果出現(xiàn)了性能下降，應(yīng)用程序支持人員就應(yīng)該能立即確定引起性能下降的是哪個(gè)portlet。在portlet 生命周期，處理回發(fā)數(shù)據(jù)和預(yù)呈現(xiàn)的那些過程對(duì)于性能監(jiān)視尤其重要。

Portal Framework 服務(wù)

　　JSP backing 文件與 JSP 協(xié)同工作，允許表示邏輯與業(yè)務(wù)邏輯分離。Backing 文件總是在JSP之后運(yùn)行，它包含大量的定制呈現(xiàn)代碼（另外，一些開發(fā)人員還會(huì)向終端系統(tǒng)進(jìn)行callout 來獲取額外的呈現(xiàn)數(shù)據(jù)）。不佳的性能常常預(yù)示著定制呈現(xiàn)代碼可能不正確。

　　在 Java 頁面流，頁面流本身完全由開發(fā)人員定義。速度上的減慢常常能由其作者診斷出來，并不會(huì)對(duì)終端系統(tǒng)造成很大的影響。將 J2EE 標(biāo)準(zhǔn)頁面流與門戶控件樹處理架構(gòu)關(guān)聯(lián)起來還可確定某個(gè)頁面流與哪個(gè)desktop 相關(guān)，這一點(diǎn)也非常有用。

WebLogic Portal 服務(wù)

　　Entitlement 系統(tǒng)為各個(gè)門戶資源提供了基于角色的授權(quán)。Entitlement 被門戶的所有方面大量使用，所以任何的減慢都會(huì)影響到整個(gè)系統(tǒng)。通常，延時(shí)的響應(yīng)和遲滯的線程大多都是由支持Entitlement的后端系統(tǒng)，比如LDAP，內(nèi)存在的問題引起的。此外，對(duì)太多的對(duì)象進(jìn)行細(xì)粒度的授權(quán)也會(huì)加大Entitlement 系統(tǒng)的開銷。

　　Personalization 服務(wù)通過advislet 實(shí)現(xiàn)，用來修改在門戶首選項(xiàng)中顯示的信息。Advislet 可使用多種機(jī)制，比如內(nèi)部規(guī)則引擎、顯式個(gè)性化，甚至事件。過度使用Personalization 系統(tǒng)也常常會(huì)引起性能問題。

　　User Profile 存儲(chǔ)庫包含額外的用戶信息，比如聯(lián)系信息。通常，延時(shí)的響應(yīng)和遲滯的線程大多都是由于后端系統(tǒng)存在的問題，比如用于支持用戶配置文件的數(shù)據(jù)庫，引起的。

　　Content Management API 與很多可用的商業(yè)內(nèi)容管理系統(tǒng)（比如Documentum）接口。如果這里產(chǎn)生了遲滯的線程，首先需要檢查的就是后端內(nèi)容系統(tǒng)是否工作正常。

結(jié)束語

　　我們非常希望本文能夠提供有用的信息，以使您對(duì)由WebLogic Portal 應(yīng)用程序的性能問題有所了解。隨著企業(yè)門戶所提供的內(nèi)容的日益復(fù)雜和普及，管理其性能和可用性的挑戰(zhàn)性也隨之增加。借助合適的工具和處理，基于門戶的應(yīng)用程序還是可以信賴的，能夠?qū)崿F(xiàn)它們所預(yù)期的業(yè)務(wù)價(jià)值。