使用IBM WebSphere Portal構建企業門戶系統是用戶比較睿智的一個選擇，但是由於Portal產品比較複雜，宕機或性能低也通常是用戶較爲頭疼的問題。經常有客戶門戶上線後出現頁面空白或無法訪問，甚至宕機的問題，令人頭疼不已。本文以IBM Portal常見性能低下或宕機的常見原因分析，並以筆者十幾年的產品實施經驗提出普衆性的解決措施。
WebSphere Portal性能瓶頸通常被劃分爲如下八大隔離區，每個隔離區的性能低下都有可能帶來用戶訪問速度慢、系統失去響應、空白頁、頁面無法顯示甚至宕機的情況。如圖：
接下來我們依次介紹這八大隔離區的問題點和性能優化策略：
一、Ajax異步調用等感受優化：
Ajax異步調用感受優化指的是通過技術手段，在其他方面都已經達到最佳優化的前提下，充分利用異步調用等技術，提高用戶速度感受，但實質上，系統的整體性能並未提升。
（一）問題分析
這種情況通常出現在登錄後進入首頁時的體驗上，尤其是當首頁部署的Portlet比較多的時候，更有甚者，多個Portlet要調用後臺的資源或者邏輯處理，每個Portlet的響應時間都比較慢，如果要等到所有Portlet初始化完畢門戶首頁才顯示出來，那麼用戶等待的時間可想而知，這將帶給用戶非常差的體驗。
（二）優化策略
IBM WebSphere Portal分爲門戶容器和Portlet容器兩部分組成，Portal容器加載完畢後再加載Portlet容器。Portal容器加載時主要是編譯並處理主題皮膚、容器運行所依賴的各種類庫、數據庫等資源；Portlet容器則是先有登錄Portlet與Ldap通信鑑權，之後每個Portlet進入init（）方法加載各種以來提交，然後進入doService（）處理各種業務邏輯，得到處理結果並傳輸回門戶後，統一編譯成Html格式，與門戶容器編譯出來的Html文件共同拼裝成一個Html文件呈現出來。多個Portlet完成業務邏輯並返回結果的時間長短不一，系統默認要等到所有Portlet回傳完所有數據後才統一呈現。那麼，響應時間最長的那個Portlet所需的時間就成爲木桶上最短的那塊木板。幸好，WebSphere Portal從7.0版本開始支持Ajax異步加載技術，本層處理的優化邏輯是採用Portlet異步加載技術，即使當只有1個Portlet處理完畢，也交由門戶容器打包呈現出來，後續每個Portlet處理完畢後逐一加載，直至加載完畢。就用戶來說，他會在較短的時間內先看到門戶首頁，和幾個Portlet欄目，這時候用戶的注意力被吸引到已經呈現出來的Portlet上面，剩餘幾個逐一加載的Portlet用戶會降低感知，所以整體上用戶的感受較好。
這是一種設計思想，需要應用到門戶系統建設的各個角落。例如：首頁主題皮膚部分可能設計成6張圖片來回滾動，形成一個動畫播放的效果。某些極端場景下例如當網絡傳輸速度較低而6張圖片的體積又較大時，如果等到6張圖片完全傳輸完畢才加載動畫播放功能，則用戶感受也會較差，變通的方法是當下載第1張圖片時，通過代碼控制先將這張圖片顯示出來，然後等其餘5張圖片下載完畢後再執行動畫播放邏輯，這樣用戶的感受也會大大提升。
二、JVM堆棧與Web線程池優化
JVM堆棧優化與Web線程池優化指的是Portal容器本身的JVM和其他各項參數的優化，也就是JVM容器本身以及垃圾回收策略的配置。
（一）問題分析
WebSphere Portal服務運行在WebSphere Application Server容器上的一個獨立服務器，既然是JVM容器就會有大小限制。處理用戶請求的每個邏輯處理都需要在JVM中開闢內存區域，用於存儲暫存數據共CPU及CPU的二級緩存調取執行二進制運算。特別是有些質量不高的代碼在佔用內存處理完之後沒有及時執行clear（）方法清空自己佔用的內存，而單獨依靠JVM本身的垃圾回收處理機制其處理能力是有限的。事實上，3.5G的內存是很容易被佔用光的。
當已經佔用的內存大於JVM本身配置的內存大小而且此時JVM還未進行垃圾回收時，就會出現沒有多餘的內存用來存儲更多用戶新增的處理請求了，這時候的表現就是新請求需要等待JVM釋放內存，而JVM如果不釋放內存，則用戶體驗就是頁面一直空白，直至超時後顯示“頁面無法響應”、“網頁無法顯示”等錯誤，甚至Hung住或者Crash掉，這就是宕機。
（二）優化策略
WebSphere Portal服務運行在WebSphere Application Server容器上的一個獨立服務器，通常64位機器上會指定JVM的最大堆棧大小爲3.5G，因爲超過3.5G後單純依賴JVM本身的垃圾回收機制在過大的JVM堆棧裏回收執行效率反而會降低很多，這裏還需要配置新生代內存的大小等。當然，如果是老式的32位機器，則JVM最大大小不可超過1.8G，因爲32位機器上最大尋址能力就是2G而已。
同時Portal本身的多線程機制當用戶訪問量較大而又不能及時釋放時也會好用較多的WebContainer，通常我們會將線程池個數調大10倍。如果日誌中爆出“some threads is hung ，waiting for…”等類似的錯誤時，很可能就是線程池已經不夠用了。當然，這時候我們首先得排除程序錯誤導致的線程池不釋放導致耗盡的原因，如果排除此項，八成就是線程池個數太少導致的。而這種錯誤非常嚴重，會直接導致頁面空白、頁面無法顯示等用戶響應丟失的情況，不久就會導致宕機。
三、主題與皮膚調優
主題與皮膚優化指的是客戶爲了適應定製化需求，會爲客戶開發一套或多套門戶主題與皮膚（即：Themes 和 Skins）。筆者已經遇到多家客戶由於主題皮膚的問題導致系統性能低下或者宕機的情況發生了。
（一）問題分析
主題皮膚導致的性能低下或宕機主要體現在兩個方面：第一，過多的主題或皮膚。很多用戶爲了豐富門戶的視覺效果，會要求開發商開發多套主題和皮膚，幾乎每張主頁面都要使用單獨的一套主題，每套主題下每個Portlet都要使用一個單獨的皮膚。我們知道，Portal裏每套主題或者每套皮膚都在單獨的一個文件夾裏三十多個文件拼裝編譯出來的。用戶在使用門戶系統時，多套主題與皮膚被加載，這意味着有數百甚至數千個jsp或者jspf,css,js,jpg等文件被加載進內存，太消耗系統資源了！這種情況多發生在一些對門戶視覺效果要求較高的客戶那裏；第二、主題或皮膚文件中存在質量不高的代碼，例如：有些主題皮膚裏存在死循環，或者需要讀取其他系統甚至互聯網上的一些資源，當外圍系統沒有及時處理並返回結果時，主題皮膚一直在等待這個資源，如果資源沒有被返回，就得等到超時，如果超時了都在等待的話，就很明顯地出現頁面空白或顯示不出來了。
（二）優化策略
筆者強烈建議，能通過一些參數化的方式解決的問題儘量通過參數化的方式，例如多個部門門戶的主題皮膚使用同一套主題，通過參數化主題上的Logo圖片，參數化文字等方式實現各個部門門戶網站的顯示效果差異；同樣的，每套主題儘量不要超過5套皮膚，還是通過參數化的方式來進行Portlet不同風格的呈現。
至於主題皮膚代碼層面，建議項目組花大力氣嚴格檢查有沒有存在死循環、讀取大數據量、不及時釋放內存等低質量代碼、等待依賴系統響應等低質量邏輯。對不懂代碼的客戶來說如果要採用逆推的方式判斷是否存在代碼質量的情況，則可以使用LoadRunner對系統進行抗疲勞測試，通過耐壓測試，讓系統低質量代碼對內存、CPU等的消耗和侵佔儘量表現出來。鼎亞科技可以爲全國的用戶×××能調優方面的免費培訓和壓力測試方面的指導、培訓。
四、SQL執行效率優化
門戶性能低或者宕機問題不僅僅是由於內存耗盡導致的，還有CPU和硬盤。SQL執行效率是同時可能對這三方面造成損耗的重要因素之一。
（一）問題分析
SQL執行效率的損害通常體現在如下兩個方面：（1）SQL慢查詢或者語句執行大數據量的查詢並返回了大數據量的查詢結果，例如某客戶一下子查詢出4000萬條用戶登錄記錄並打印在了主題文件裏，這些大數據量既會佔用內存，又會消耗CPU，甚至寫入一些硬盤文件，天長日久導致硬盤被佔滿而宕機。SQL慢查詢則會帶來大量的用戶等待時間。（2）SQL語句執行次數過多或死循環。系統要查詢一組數據時，需要到多張表裏執行多組查詢並拼裝處理返回的結果，或者某些極端條件出發SQL執行死循環，既消耗大量的CPU資源又不返回結果，宕機也就是不可避免的了。
（二）優化策略
務必通過強壯的代碼審查（Code Review）識別出SQL慢查詢、大數據量查詢、死循環等問題，併合理設計表結構，合理設計SQL語句。與上一節相同，對不懂代碼的客戶來說如果要採用逆推的方式判斷是否存在代碼質量的情況，則可以使用LoadRunner對系統進行抗疲勞測試，通過耐壓測試，讓系統低質量代碼對內存、CPU等的消耗和侵佔儘量表現出來。鼎亞科技可以爲全國的用戶×××能調優方面的免費培訓和壓力測試方面的指導、培訓。所謂的抗疲勞測試指的是，錄製儘可能覆蓋所有頁面、所有邏輯的功能點，並設置LoadRunner在沒有思考時間的前提下，進行長達72小時的耐久性測試，所謂“日久見人心”，哪怕SQL執行效率稍微有一點點低下，資源有一點點沒有及時釋放的，通過高強度的耐壓測試，也會讓問題無限放大，最終暴露出來。
五、數據庫性能優化
數據庫性能優化指的是數據庫本身的參數優化，以及WebSphere使用數據源連接池的參數優化。
（一）問題分析
IBM WebSphere Portal使用數據源連接池即長連接的方式提供數據庫服務，所以不合理的數據源連接池配置會導致數據庫處理邏輯等待時間過長或者宕機。例如：如果某些Portlet應用頻繁讀取數據庫，而連接池的個數過低，就會有大量的數據庫讀寫邏輯在排隊等待數據庫連接，甚至超時後導致宕機，最直接的後果就是用戶的很多Portlet應用一直初始化不出來，原因是在等待其他邏輯釋放數據源連接池後進行數據庫讀寫操作。
（二）優化策略
通常我們會在WAS控制檯上配置數據源連接池的個數爲系統默認的3-6倍，具體視各家客戶的門戶內容使用數據庫的頻率高低而定。數據源連接池個數過低，會造成Portlet邏輯排隊等待拉長響應時間；個數過高則會導致系統可用內存降低，因爲每個數據源連接池會佔用大約3M左右的內存，如果配置幾百個數據源連接池，則僅僅數用於數據庫連接的內存就會佔用1個多G，計算我們配置了3.5G的JVM，也沒剩多少計算內存用於門戶的邏輯處理，同樣也會導致系統的性能降低或宕機。這裏還要強調數據源連接池的過期時間，不恰當的TimeOut也會帶來等待響應或系統無法處理用戶的正常請求。最準確的個數配置來源於最佳實踐。直白的說，就是通過設置不同的參數後進行合理配置的LoadRunner壓力測試，壓力測試場景的設計儘量貼近用戶使用的真實場景，來模擬生產環境的真實狀況，然後通過對比LoadRunner壓力測試表現最好的那組，確定數據源連接池的最佳配置。
額外的，通常數據庫服務器和門戶服務器是不同的服務器，中間架設防火牆的客戶比例非常高，這裏我們要強調一下一定協助客戶合理配置防火牆策略，因爲防火牆切斷門戶與數據庫之間的長連接而導致的門戶宕機案例非常之高。
六、數據/數據集優化
數據與數據集優化指的是無論Portal容器還是Portlet容器讀寫的數據量大小問題，數據量過大會消耗大量時間和空間資源，會導致系統性能低下或宕機。
（一）問題分析
Portal主題皮膚裏的代碼和（或）Portlet應用邏輯代碼在執行大數據量操作時，會消耗大量的時間資源、空間資源；時間資源體現在CPU處理上，空間資源體現在內存佔用上。無論是CPU過於繁忙還是內存消耗過大都是一種危險的事，最常用的就是分段讀寫、分頁顯示、大數據轉移等問題。
（1）大數據量讀寫。數據庫執行大數據量讀寫時，會消耗大量的CPU時間和內存佔用，用戶併發量一上升，就很容易導致性能問題。
（2）分頁顯示。這個無需多說，用戶通常看的是前3頁，如果一下子把幾百頁讀取過來，內存空間的佔用是巨大的。
（3）大數據轉移，指的是某些表裏可能存儲非常大量的數據，例如用戶登陸日誌，數據積累越來越多，讀寫速度就會越來越慢，系統資源消耗就會越來越大，性能也就越來越低了。
（二）優化策略
針對於常見的這些問題，分別介紹調整策略。這部分其實最多的也是與常規Java開發相同，請自行參考。
（1）分段讀寫指的是，邏輯代碼在讀寫數據時，儘量不要大數據量讀寫，例如向數據庫或文件系統中一次寫入超過10萬條數據，或者讀入上百萬條數據，這種效率肯定極低，嘗試修改設計，優化讀取邏輯。
（2）分頁顯示。這個無需多說，每次讀寫最多3頁，等用戶點擊翻頁時再讀取更多的數據。
（3）大數據轉移。適用於某些表裏要存儲大數據量時，最好不要超過千萬條記錄的級別，通常用在用戶登錄日誌等，隨着使用時間的推移，表中的記錄條數越來越多，讀取的時候也很容易消耗資源。
七、Portlet代碼與邏輯優化
Portlet開發實際上與傳統的Java開發並無二致，Portlet等待數據庫連接、死循環等帶來的系統性能低下，成爲Portlet層面優化的問題本質。
（一）問題分析
Portlet代碼導致性能低下的情況通常有：（1）執行邏輯效率低或死循環導致Portlet響應異常地慢，例如要到十幾套系統裏讀取各個系統的待辦信息等；（2）Portlet等待某些資源而這些資源沒有及時加載或者壓根就加載不出來，而Portlet端有沒有處理讀取不出來時候的出錯處理，導致Portlet一直在等待資源，系統線程Hung住也就很正常了。
（二）優化策略
這需要合理設計Portlet實現邏輯。例如：統一待辦Portlet，我們可以採用逆向推送的方式，當各個業務系統產生新的待辦事項時，主動推送到門戶緩衝數據庫（可以認爲是Broker層），然後Portlet直接到緩衝數據庫一個表裏讀取待辦條目，這樣可以提高Portlet性能達數十倍。
第二，通過嚴格的代碼檢查消除Portlet中資源等待、死循環等問題。這個問題的檢查與普通的Java開發並無二致，本文不再贅述。
八、網絡傳輸（包大小）優化
顯示邏輯和打包邏輯優化多發生在網絡速度不太高的客戶場景中，尤其是部署在雲端或者互聯網上的客戶，指的是過大的數據量傳輸導致了用戶響應時間太慢，慢到用戶以爲系統宕機了。備註：如果傳輸時間超時，那就真宕機了。
（一）問題分析
我們知道，所有用戶的請求都是通過服務器端唯一的網線出口與用戶的客戶端電腦（或手機）建立比特流傳輸的。建設每個用戶訪問門戶需要傳輸3M的數據流量，這3M包含了邏輯處理完成之後編譯出來的css文件，jss文件，html文件，jpg/png等圖片文件，假設有300個用戶在併發訪問，則這300個用戶一共需要傳輸3Mx300=900M數據流量。如果我們服務器申請的帶寬是百兆，也就是每秒鐘能傳輸12.5M數據，則即使出去邏輯處理的時間，進網路傳輸的消耗，就需要900M除以12.5M/S等於72秒，這是一個多麼龐大的數據，每個用戶光等待傳輸就要等待72秒
（二）優化策略
在不影響圖片觀看效果的情況下，我們建議用戶儘量降低圖片的大小，對程序開發者來說，在不影響功能的前提下，儘量爲js文件、css文件等減肥，將其體積降到最低，儘量降低網路傳輸帶來的用戶體驗消耗。作爲系統架構師或項目經理，要充分調研，充分考慮到真實的用戶併發情況，並協助用戶購買或分配合理的網絡帶寬。