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