IBM WebSphere Portal當機或效能低常見問題分析 及解決措施

使用 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檔案等減肥，將其體積降到最低，儘量降低網路傳輸帶來的使用者體驗消耗。作為系統架構師或專案經理，要充分調研，充分考慮到真實的使用者併發情況，並協助使用者購買或分配合理的網路頻寬。