使用IBM WebSphere Portal構(gòu)建企業(yè)門戶系統(tǒng)是用戶比較睿智的一個(gè)選擇，但是由于Portal產(chǎn)品比較復(fù)雜，宕機(jī)或性能低也通常是用戶較為頭疼的問題。經(jīng)常有客戶門戶上線后出現(xiàn)頁面空白或無法訪問，甚至宕機(jī)的問題，令人頭疼不已。本文以IBM Portal常見性能低下或宕機(jī)的常見原因分析，并以筆者十幾年的產(chǎn)品實(shí)施經(jīng)驗(yàn)提出普眾性的解決措施。

創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設(shè)、成都網(wǎng)站制作、網(wǎng)站營銷推廣、網(wǎng)站開發(fā)設(shè)計(jì)，對服務(wù)成都三維植被網(wǎng)等多個(gè)行業(yè)擁有豐富的網(wǎng)站建設(shè)及推廣經(jīng)驗(yàn)。創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司成立于2013年,提供專業(yè)網(wǎng)站制作報(bào)價(jià)服務(wù),我們深知市場的競爭激烈，認(rèn)真對待每位客戶，為客戶提供賞心悅目的作品。 與客戶共同發(fā)展進(jìn)步，是我們永遠(yuǎn)的責(zé)任！

WebSphere Portal性能瓶頸通常被劃分為如下八大隔離區(qū)，每個(gè)隔離區(qū)的性能低下都有可能帶來用戶訪問速度慢、系統(tǒng)失去響應(yīng)、空白頁、頁面無法顯示甚至宕機(jī)的情況。如圖：

接下來我們依次介紹這八大隔離區(qū)的問題點(diǎn)和性能優(yōu)化策略：

一、Ajax異步調(diào)用等感受優(yōu)化：

Ajax異步調(diào)用感受優(yōu)化指的是通過技術(shù)手段，在其他方面都已經(jīng)達(dá)到最佳優(yōu)化的前提下，充分利用異步調(diào)用等技術(shù)，提高用戶速度感受，但實(shí)質(zhì)上，系統(tǒng)的整體性能并未提升。

（一）問題分析

這種情況通常出現(xiàn)在登錄后進(jìn)入首頁時(shí)的體驗(yàn)上，尤其是當(dāng)首頁部署的Portlet比較多的時(shí)候，更有甚者，多個(gè)Portlet要調(diào)用后臺(tái)的資源或者邏輯處理，每個(gè)Portlet的響應(yīng)時(shí)間都比較慢，如果要等到所有Portlet初始化完畢門戶首頁才顯示出來，那么用戶等待的時(shí)間可想而知，這將帶給用戶非常差的體驗(yàn)。

（二）優(yōu)化策略

IBM WebSphere Portal分為門戶容器和Portlet容器兩部分組成，Portal容器加載完畢后再加載Portlet容器。Portal容器加載時(shí)主要是編譯并處理主題皮膚、容器運(yùn)行所依賴的各種類庫、數(shù)據(jù)庫等資源；Portlet容器則是先有登錄Portlet與Ldap通信鑒權(quán)，之后每個(gè)Portlet進(jìn)入init（）方法加載各種以來提交，然后進(jìn)入doService（）處理各種業(yè)務(wù)邏輯，得到處理結(jié)果并傳輸回門戶后，統(tǒng)一編譯成Html格式，與門戶容器編譯出來的Html文件共同拼裝成一個(gè)Html文件呈現(xiàn)出來。多個(gè)Portlet完成業(yè)務(wù)邏輯并返回結(jié)果的時(shí)間長短不一，系統(tǒng)默認(rèn)要等到所有Portlet回傳完所有數(shù)據(jù)后才統(tǒng)一呈現(xiàn)。那么，響應(yīng)時(shí)間最長的那個(gè)Portlet所需的時(shí)間就成為木桶上最短的那塊木板。幸好，WebSphere Portal從7.0版本開始支持Ajax異步加載技術(shù)，本層處理的優(yōu)化邏輯是采用Portlet異步加載技術(shù)，即使當(dāng)只有1個(gè)Portlet處理完畢，也交由門戶容器打包呈現(xiàn)出來，后續(xù)每個(gè)Portlet處理完畢后逐一加載，直至加載完畢。就用戶來說，他會(huì)在較短的時(shí)間內(nèi)先看到門戶首頁，和幾個(gè)Portlet欄目，這時(shí)候用戶的注意力被吸引到已經(jīng)呈現(xiàn)出來的Portlet上面，剩余幾個(gè)逐一加載的Portlet用戶會(huì)降低感知，所以整體上用戶的感受較好。

這是一種設(shè)計(jì)思想，需要應(yīng)用到門戶系統(tǒng)建設(shè)的各個(gè)角落。例如：首頁主題皮膚部分可能設(shè)計(jì)成6張圖片來回滾動(dòng)，形成一個(gè)動(dòng)畫播放的效果。某些極端場景下例如當(dāng)網(wǎng)絡(luò)傳輸速度較低而6張圖片的體積又較大時(shí)，如果等到6張圖片完全傳輸完畢才加載動(dòng)畫播放功能，則用戶感受也會(huì)較差，變通的方法是當(dāng)下載第1張圖片時(shí)，通過代碼控制先將這張圖片顯示出來，然后等其余5張圖片下載完畢后再執(zhí)行動(dòng)畫播放邏輯，這樣用戶的感受也會(huì)大大提升。

二、JVM堆棧與Web線程池優(yōu)化

JVM堆棧優(yōu)化與Web線程池優(yōu)化指的是Portal容器本身的JVM和其他各項(xiàng)參數(shù)的優(yōu)化，也就是JVM容器本身以及垃圾回收策略的配置。

（一）問題分析

WebSphere Portal服務(wù)運(yùn)行在WebSphere Application Server容器上的一個(gè)獨(dú)立服務(wù)器，既然是JVM容器就會(huì)有大小限制。處理用戶請求的每個(gè)邏輯處理都需要在JVM中開辟內(nèi)存區(qū)域，用于存儲(chǔ)暫存數(shù)據(jù)共CPU及CPU的二級緩存調(diào)取執(zhí)行二進(jìn)制運(yùn)算。特別是有些質(zhì)量不高的代碼在占用內(nè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)沒有多余的內(nèi)存用來存儲(chǔ)更多用戶新增的處理請求了，這時(shí)候的表現(xiàn)就是新請求需要等待JVM釋放內(nèi)存，而JVM如果不釋放內(nèi)存，則用戶體驗(yàn)就是頁面一直空白，直至超時(shí)后顯示“頁面無法響應(yīng)”、“網(wǎng)頁無法顯示”等錯(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)槌^3.5G后單純依賴JVM本身的垃圾回收機(jī)制在過大的JVM堆棧里回收執(zhí)行效率反而會(huì)降低很多，這里還需要配置新生代內(nèi)存的大小等。當(dāng)然，如果是老式的32位機(jī)器，則JVM大大小不可超過1.8G，因?yàn)?2位機(jī)器上大尋址能力就是2G而已。

同時(shí)Portal本身的多線程機(jī)制當(dāng)用戶訪問量較大而又不能及時(shí)釋放時(shí)也會(huì)好用較多的WebContainer，通常我們會(huì)將線程池個(gè)數(shù)調(diào)大10倍。如果日志中爆出“some threads is hung ，waiting for…”等類似的錯(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īng)丟失的情況，不久就會(huì)導(dǎo)致宕機(jī)。

三、主題與皮膚調(diào)優(yōu)

主題與皮膚優(yōu)化指的是客戶為了適應(yīng)定制化需求，會(huì)為客戶開發(fā)一套或多套門戶主題與皮膚（即：Themes 和 Skins）。筆者已經(jīng)遇到多家客戶由于主題皮膚的問題導(dǎo)致系統(tǒng)性能低下或者宕機(jī)的情況發(fā)生了。

（一）問題分析

主題皮膚導(dǎo)致的性能低下或宕機(jī)主要體現(xiàn)在兩個(gè)方面：第一，過多的主題或皮膚。很多用戶為了豐富門戶的視覺效果，會(huì)要求開發(fā)商開發(fā)多套主題和皮膚，幾乎每張主頁面都要使用單獨(dú)的一套主題，每套主題下每個(gè)Portlet都要使用一個(gè)單獨(dú)的皮膚。我們知道，Portal里每套主題或者每套皮膚都在單獨(dú)的一個(gè)文件夾里三十多個(gè)文件拼裝編譯出來的。用戶在使用門戶系統(tǒng)時(shí)，多套主題與皮膚被加載，這意味著有數(shù)百甚至數(shù)千個(gè)jsp或者jspf,css,js,jpg等文件被加載進(jìn)內(nèi)存，太消耗系統(tǒng)資源了！這種情況多發(fā)生在一些對門戶視覺效果要求較高的客戶那里；第二、主題或皮膚文件中存在質(zhì)量不高的代碼，例如：有些主題皮膚里存在死循環(huán)，或者需要讀取其他系統(tǒng)甚至互聯(lián)網(wǎng)上的一些資源，當(dāng)外圍系統(tǒng)沒有及時(shí)處理并返回結(jié)果時(shí)，主題皮膚一直在等待這個(gè)資源，如果資源沒有被返回，就得等到超時(shí)，如果超時(shí)了都在等待的話，就很明顯地出現(xiàn)頁面空白或顯示不出來了。

（二）優(yōu)化策略

筆者強(qiáng)烈建議，能通過一些參數(shù)化的方式解決的問題盡量通過參數(shù)化的方式，例如多個(gè)部門門戶的主題皮膚使用同一套主題，通過參數(shù)化主題上的Logo圖片，參數(shù)化文字等方式實(shí)現(xiàn)各個(gè)部門門戶網(wǎng)站的顯示效果差異；同樣的，每套主題盡量不要超過5套皮膚，還是通過參數(shù)化的方式來進(jìn)行Portlet不同風(fēng)格的呈現(xiàn)。

至于主題皮膚代碼層面，建議項(xiàng)目組花大力氣嚴(yán)格檢查有沒有存在死循環(huán)、讀取大數(shù)據(jù)量、不及時(shí)釋放內(nèi)存等低質(zhì)量代碼、等待依賴系統(tǒng)響應(yīng)等低質(zhì)量邏輯。對不懂代碼的客戶來說如果要采用逆推的方式判斷是否存在代碼質(zhì)量的情況，則可以使用LoadRunner對系統(tǒng)進(jìn)行抗疲勞測試，通過耐壓測試，讓系統(tǒng)低質(zhì)量代碼對內(nèi)存、CPU等的消耗和侵占盡量表現(xiàn)出來。鼎亞科技可以為全國的用戶×××能調(diào)優(yōu)方面的免費(fèi)培訓(xùn)和壓力測試方面的指導(dǎo)、培訓(xùn)。

四、SQL執(zhí)行效率優(yōu)化

門戶性能低或者宕機(jī)問題不僅僅是由于內(nèi)存耗盡導(dǎo)致的，還有CPU和硬盤。SQL執(zhí)行效率是同時(shí)可能對這三方面造成損耗的重要因素之一。

（一）問題分析

SQL執(zhí)行效率的損害通常體現(xiàn)在如下兩個(gè)方面：（1）SQL慢查詢或者語句執(zhí)行大數(shù)據(jù)量的查詢并返回了大數(shù)據(jù)量的查詢結(jié)果，例如某客戶一下子查詢出4000萬條用戶登錄記錄并打印在了主題文件里，這些大數(shù)據(jù)量既會(huì)占用內(nèi)存，又會(huì)消耗CPU，甚至寫入一些硬盤文件，天長日久導(dǎo)致硬盤被占滿而宕機(jī)。SQL慢查詢則會(huì)帶來大量的用戶等待時(shí)間。（2）SQL語句執(zhí)行次數(shù)過多或死循環(huán)。系統(tǒng)要查詢一組數(shù)據(jù)時(shí)，需要到多張表里執(zhí)行多組查詢并拼裝處理返回的結(jié)果，或者某些極端條件出發(fā)SQL執(zhí)行死循環(huán)，既消耗大量的CPU資源又不返回結(jié)果，宕機(jī)也就是不可避免的了。

（二）優(yōu)化策略

務(wù)必通過強(qiáng)壯的代碼審查（Code Review）識(shí)別出SQL慢查詢、大數(shù)據(jù)量查詢、死循環(huán)等問題，并合理設(shè)計(jì)表結(jié)構(gòu)，合理設(shè)計(jì)SQL語句。與上一節(jié)相同，對不懂代碼的客戶來說如果要采用逆推的方式判斷是否存在代碼質(zhì)量的情況，則可以使用LoadRunner對系統(tǒng)進(jìn)行抗疲勞測試，通過耐壓測試，讓系統(tǒng)低質(zhì)量代碼對內(nèi)存、CPU等的消耗和侵占盡量表現(xiàn)出來。鼎亞科技可以為全國的用戶×××能調(diào)優(yōu)方面的免費(fèi)培訓(xùn)和壓力測試方面的指導(dǎo)、培訓(xùn)。所謂的抗疲勞測試指的是，錄制盡可能覆蓋所有頁面、所有邏輯的功能點(diǎn)，并設(shè)置LoadRunner在沒有思考時(shí)間的前提下，進(jìn)行長達(dá)72小時(shí)的耐久性測試，所謂“日久見人心”，哪怕SQL執(zhí)行效率稍微有一點(diǎn)點(diǎn)低下，資源有一點(diǎn)點(diǎn)沒有及時(shí)釋放的，通過高強(qiáng)度的耐壓測試，也會(huì)讓問題無限放大，最終暴露出來。

五、數(shù)據(jù)庫性能優(yōu)化

數(shù)據(jù)庫性能優(yōu)化指的是數(shù)據(jù)庫本身的參數(shù)優(yōu)化，以及WebSphere使用數(shù)據(jù)源連接池的參數(shù)優(yōu)化。

（一）問題分析

IBM WebSphere Portal使用數(shù)據(jù)源連接池即長連接的方式提供數(shù)據(jù)庫服務(wù)，所以不合理的數(shù)據(jù)源連接池配置會(huì)導(dǎo)致數(shù)據(jù)庫處理邏輯等待時(shí)間過長或者宕機(jī)。例如：如果某些Portlet應(yīng)用頻繁讀取數(shù)據(jù)庫，而連接池的個(gè)數(shù)過低，就會(huì)有大量的數(shù)據(jù)庫讀寫邏輯在排隊(duì)等待數(shù)據(jù)庫連接，甚至超時(shí)后導(dǎo)致宕機(jī)，最直接的后果就是用戶的很多Portlet應(yīng)用一直初始化不出來，原因是在等待其他邏輯釋放數(shù)據(jù)源連接池后進(jìn)行數(shù)據(jù)庫讀寫操作。

（二）優(yōu)化策略

通常我們會(huì)在WAS控制臺(tái)上配置數(shù)據(jù)源連接池的個(gè)數(shù)為系統(tǒng)默認(rèn)的3-6倍，具體視各家客戶的門戶內(nèi)容使用數(shù)據(jù)庫的頻率高低而定。數(shù)據(jù)源連接池個(gè)數(shù)過低，會(huì)造成Portlet邏輯排隊(duì)等待拉長響應(yīng)時(shí)間；個(gè)數(shù)過高則會(huì)導(dǎo)致系統(tǒng)可用內(nèi)存降低，因?yàn)槊總€(gè)數(shù)據(jù)源連接池會(huì)占用大約3M左右的內(nèi)存，如果配置幾百個(gè)數(shù)據(jù)源連接池，則僅僅數(shù)用于數(shù)據(jù)庫連接的內(nèi)存就會(huì)占用1個(gè)多G，計(jì)算我們配置了3.5G的JVM，也沒剩多少計(jì)算內(nèi)存用于門戶的邏輯處理，同樣也會(huì)導(dǎo)致系統(tǒng)的性能降低或宕機(jī)。這里還要強(qiáng)調(diào)數(shù)據(jù)源連接池的過期時(shí)間，不恰當(dāng)?shù)腡imeOut也會(huì)帶來等待響應(yīng)或系統(tǒng)無法處理用戶的正常請求。最準(zhǔn)確的個(gè)數(shù)配置來源于最佳實(shí)踐。直白的說，就是通過設(shè)置不同的參數(shù)后進(jìn)行合理配置的LoadRunner壓力測試，壓力測試場景的設(shè)計(jì)盡量貼近用戶使用的真實(shí)場景，來模擬生產(chǎn)環(huán)境的真實(shí)狀況，然后通過對比LoadRunner壓力測試表現(xiàn)最好的那組，確定數(shù)據(jù)源連接池的最佳配置。

額外的，通常數(shù)據(jù)庫服務(wù)器和門戶服務(wù)器是不同的服務(wù)器，中間架設(shè)防火墻的客戶比例非常高，這里我們要強(qiáng)調(diào)一下一定協(xié)助客戶合理配置防火墻策略，因?yàn)榉阑饓η袛嚅T戶與數(shù)據(jù)庫之間的長連接而導(dǎo)致的門戶宕機(jī)案例非常之高。

六、數(shù)據(jù)/數(shù)據(jù)集優(yōu)化

數(shù)據(jù)與數(shù)據(jù)集優(yōu)化指的是無論P(yáng)ortal容器還是Portlet容器讀寫的數(shù)據(jù)量大小問題，數(shù)據(jù)量過大會(huì)消耗大量時(shí)間和空間資源，會(huì)導(dǎo)致系統(tǒng)性能低下或宕機(jī)。

（一）問題分析

Portal主題皮膚里的代碼和（或）Portlet應(yīng)用邏輯代碼在執(zhí)行大數(shù)據(jù)量操作時(shí)，會(huì)消耗大量的時(shí)間資源、空間資源；時(shí)間資源體現(xiàn)在CPU處理上，空間資源體現(xiàn)在內(nèi)存占用上。無論是CPU過于繁忙還是內(nèi)存消耗過大都是一種危險(xiǎn)的事，最常用的就是分段讀寫、分頁顯示、大數(shù)據(jù)轉(zhuǎn)移等問題。

（1）大數(shù)據(jù)量讀寫。數(shù)據(jù)庫執(zhí)行大數(shù)據(jù)量讀寫時(shí)，會(huì)消耗大量的CPU時(shí)間和內(nèi)存占用，用戶并發(fā)量一上升，就很容易導(dǎo)致性能問題。

（2）分頁顯示。這個(gè)無需多說，用戶通常看的是前3頁，如果一下子把幾百頁讀取過來，內(nèi)存空間的占用是巨大的。

（3）大數(shù)據(jù)轉(zhuǎn)移，指的是某些表里可能存儲(chǔ)非常大量的數(shù)據(jù)，例如用戶登陸日志，數(shù)據(jù)積累越來越多，讀寫速度就會(huì)越來越慢，系統(tǒng)資源消耗就會(huì)越來越大，性能也就越來越低了。

（二）優(yōu)化策略

針對于常見的這些問題，分別介紹調(diào)整策略。這部分其實(shí)最多的也是與常規(guī)Java開發(fā)相同，請自行參考。

（1）分段讀寫指的是，邏輯代碼在讀寫數(shù)據(jù)時(shí)，盡量不要大數(shù)據(jù)量讀寫，例如向數(shù)據(jù)庫或文件系統(tǒng)中一次寫入超過10萬條數(shù)據(jù)，或者讀入上百萬條數(shù)據(jù)，這種效率肯定極低，嘗試修改設(shè)計(jì)，優(yōu)化讀取邏輯。

（2）分頁顯示。這個(gè)無需多說，每次讀寫最多3頁，等用戶點(diǎn)擊翻頁時(shí)再讀取更多的數(shù)據(jù)。

（3）大數(shù)據(jù)轉(zhuǎn)移。適用于某些表里要存儲(chǔ)大數(shù)據(jù)量時(shí)，最好不要超過千萬條記錄的級別，通常用在用戶登錄日志等，隨著使用時(shí)間的推移，表中的記錄條數(shù)越來越多，讀取的時(shí)候也很容易消耗資源。

七、Portlet代碼與邏輯優(yōu)化

Portlet開發(fā)實(shí)際上與傳統(tǒng)的Java開發(fā)并無二致，Portlet等待數(shù)據(jù)庫連接、死循環(huán)等帶來的系統(tǒng)性能低下，成為Portlet層面優(yōu)化的問題本質(zhì)。

（一）問題分析

Portlet代碼導(dǎo)致性能低下的情況通常有：（1）執(zhí)行邏輯效率低或死循環(huán)導(dǎo)致Portlet響應(yīng)異常地慢，例如要到十幾套系統(tǒng)里讀取各個(gè)系統(tǒng)的待辦信息等；（2）Portlet等待某些資源而這些資源沒有及時(shí)加載或者壓根就加載不出來，而Portlet端有沒有處理讀取不出來時(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)推送到門戶緩沖數(shù)據(jù)庫（可以認(rèn)為是Broker層），然后Portlet直接到緩沖數(shù)據(jù)庫一個(gè)表里讀取待辦條目，這樣可以提高Portlet性能達(dá)數(shù)十倍。

第二，通過嚴(yán)格的代碼檢查消除Portlet中資源等待、死循環(huán)等問題。這個(gè)問題的檢查與普通的Java開發(fā)并無二致，本文不再贅述。

八、網(wǎng)絡(luò)傳輸（包大小）優(yōu)化

顯示邏輯和打包邏輯優(yōu)化多發(fā)生在網(wǎng)絡(luò)速度不太高的客戶場景中，尤其是部署在云端或者互聯(lián)網(wǎng)上的客戶，指的是過大的數(shù)據(jù)量傳輸導(dǎo)致了用戶響應(yīng)時(shí)間太慢，慢到用戶以為系統(tǒng)宕機(jī)了。備注：如果傳輸時(shí)間超時(shí)，那就真宕機(jī)了。

（一）問題分析

我們知道，所有用戶的請求都是通過服務(wù)器端唯一的網(wǎng)線出口與用戶的客戶端電腦（或手機(jī)）建立比特流傳輸?shù)摹＝ㄔO(shè)每個(gè)用戶訪問門戶需要傳輸3M的數(shù)據(jù)流量，這3M包含了邏輯處理完成之后編譯出來的css文件，jss文件，html文件，jpg/png等圖片文件，假設(shè)有300個(gè)用戶在并發(fā)訪問，則這300個(gè)用戶一共需要傳輸3Mx300=900M數(shù)據(jù)流量。如果我們服務(wù)器申請的帶寬是百兆，也就是每秒鐘能傳輸12.5M數(shù)據(jù)，則即使出去邏輯處理的時(shí)間，進(jìn)網(wǎng)路傳輸?shù)南模托枰?00M除以12.5M/S等于72秒，這是一個(gè)多么龐大的數(shù)據(jù)，每個(gè)用戶光等待傳輸就要等待72秒

（二）優(yōu)化策略

在不影響圖片觀看效果的情況下，我們建議用戶盡量降低圖片的大小，對程序開發(fā)者來說，在不影響功能的前提下，盡量為js文件、css文件等減肥，將其體積降到最低，盡量降低網(wǎng)路傳輸帶來的用戶體驗(yàn)消耗。作為系統(tǒng)架構(gòu)師或項(xiàng)目經(jīng)理，要充分調(diào)研，充分考慮到真實(shí)的用戶并發(fā)情況，并協(xié)助用戶購買或分配合理的網(wǎng)絡(luò)帶寬。

網(wǎng)站名稱：IBMWebSpherePortal宕機(jī)或性能低常見問題分析及解決措施-創(chuàng)新互聯(lián)
文章轉(zhuǎn)載：http://www.chinadenli.net/article22/dgescc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供標(biāo)簽優(yōu)化、定制網(wǎng)站、品牌網(wǎng)站制作、虛擬主機(jī)、微信小程序、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)