所謂大型網(wǎng)站就是訪問量與流量都很大的一些網(wǎng)站，因此在建站初期就要考慮好當流量達到某一級別是是否可以支撐網(wǎng)站繼續(xù)正常運營下去。其中主要考慮的方面有幾點：數(shù)據(jù)庫壓力，網(wǎng)頁優(yōu)化，服務(wù)器負載。

一、

1、數(shù)據(jù)庫壓力問題 所有的壓力較終都會反映到數(shù)據(jù)庫方面，一定要對數(shù)據(jù)庫有一個整體的規(guī)劃。 可以按照業(yè)務(wù)、區(qū)域等等特性對數(shù)據(jù)庫進行配置，可以考慮分庫、使用rac、分區(qū)、分表等等策略，確保數(shù)據(jù)庫能正常的進行交易。

2、事務(wù)問題 你采用了兩種類型數(shù)據(jù)庫，一個SQL Server、一個oracle，如果一個交易需要在兩個數(shù)據(jù)庫中操作，那么必須考慮到分布式事務(wù)，你應(yīng)該仔細的設(shè)計你的系統(tǒng)，來避免使用分布式事務(wù)，以避免分布式事務(wù)帶來更多的數(shù)據(jù)庫壓力和其它問題。推薦你采用延遲提交的策略(并不保證數(shù)據(jù)的完整)，來避免分布式事務(wù)的問題，畢竟commit失敗的幾率很低。(某個超大型系統(tǒng)，有3套數(shù)據(jù)庫，也是采用的延遲提交策略，避免分布式事務(wù)帶來的對數(shù)據(jù)庫過大的壓力)。

看到了你在應(yīng)用前端(weblogic EJB)采用了F5，我個人不是很贊同這個方案，雖然F5是一個好的L4產(chǎn)品，也能基于第7層做負載均衡和容災(zāi)。但是一個有事務(wù)交易的EJB，如果采用了這種方案，把不需要使用分布式事務(wù)的交易變成了分布式交易，試想，一個web如果在一個請求中，訪問了后端兩個EJB，那么L4就會有可能把請求分發(fā)到不同的服務(wù)器上，沒有對事務(wù)維持在一個服務(wù)器中，就不能使用本地事務(wù)。同樣，一個web，訪問后端一個請求，這個請求中需要3個EJB，那么極有可能把這3個請求分發(fā)到不同的服務(wù)器，又造成了分布式事務(wù)。weblogic是一個好的J2EE產(chǎn)品，對這種有事務(wù)關(guān)聯(lián)的負載均衡，它會優(yōu)先考慮采用一個服務(wù)器里面的應(yīng)用，這樣就采用了本地事務(wù)，提高了響應(yīng)速度，減小了分布式事務(wù)對應(yīng)用和數(shù)據(jù)庫的壓力。

3、web的優(yōu)化 我個人認為，一個商業(yè)的應(yīng)用，硬件的投資可能不是主要的瓶頸，往往可維護性，可擴展性是較主要的問題。

沒有必要采用不成熟的方案，要更多的使用成熟的方案，將靜態(tài)、圖片獨立使用不同的服務(wù)器，對于常態(tài)的靜態(tài)文件，采用E-TAG或者客戶端緩存，google很多就是這樣干的。對于熱點的功能，考慮使用有效裝載到內(nèi)存，保證絕對的響應(yīng)速度，對于需要頻繁訪問的熱點數(shù)據(jù)，采用集中緩存(多個可以采用負載均衡)，減輕數(shù)據(jù)庫的壓力，比如：很多配置信息，操作員信息等等。

對了，對于幾乎除二進制文件，都應(yīng)該在L4上配置基于硬件的壓縮方案，減少網(wǎng)絡(luò)的流量。提高用戶使用的感知。

4、網(wǎng)絡(luò)問題 你不可能要求所有的使用人員，都和你的服務(wù)器在一個運營商的網(wǎng)絡(luò)內(nèi)，可以考慮采用鏡像、多路網(wǎng)絡(luò)接入、基于DNS的負載均衡。如果有足夠的投資，可以采用CDN(內(nèi)容分發(fā)網(wǎng))，減輕你的服務(wù)器壓力。

二、

F5的負載均衡 是必不可少的，他的每秒點擊量能達到將近30萬，并且它有會話的 粘性，只要是同一個ip發(fā)過來的請求，它就會把它分到同一臺機器的，不用 擔心分發(fā)錯誤的?，F(xiàn)在的問題是apache和tomcat的能力不平衡，動態(tài)的內(nèi)容壓力太大，不是數(shù)據(jù)庫的壓力，我們的數(shù)據(jù)庫 oracle是RAC群集。性能很好

三、

tomcat為什么死掉?當時CPU或者內(nèi)存的占用率是多少?看看其中JVM占用了多少?有沒有OOM的錯誤?不可能20臺tomcat只能支撐5000的并發(fā)。。。以前做過單臺的resin峰值到3K都是綽綽有余的。。。把緩存做好，減少動態(tài)查詢

四、

1、F5的使用 F5不光可以做web的負載均衡，也可以做基于第4層的負載均衡。 比如：銀行接口，大部分基于socket通訊的，就可以在前面架設(shè)一套F5設(shè)備，將請求分發(fā)到不同的服務(wù)器上。

大部分使用F5都是在web層次上，如果使用基于源IP地址的策略，有很多客戶端都是基于代理服務(wù)器，這個時候源IP地址是一樣的，其實并沒有把這些用戶給分發(fā)到不同的服務(wù)器上，建議采用基于cookie insert的方式，采用cookie的會話保持策略，loadbalance的算法，需要仔細的結(jié)合自己的應(yīng)用的實際情況來設(shè)置。

2、大并發(fā)的問題 現(xiàn)在你得到了一個大概的系統(tǒng)能承受的并發(fā)，但是還達不到系統(tǒng)的設(shè)計目標。 應(yīng)該從應(yīng)用的角度去分析這個問題，web方面，通過工具(httplook)，檢查一下客戶端發(fā)起的請求都是什么響應(yīng)狀態(tài)，如果看到很多304請求狀態(tài)，你需要優(yōu)化你的url緩存，看一下每個url的耗費時間，仔細針對比較慢的進行調(diào)優(yōu);對于tomcat或者weblogic，在高并發(fā)的情況下，用kill -3  ，獲得ThreadDump(HeapDump需要特殊的設(shè)置)，看一下在高并發(fā)下，jvm的線程到底在干什么，仔細的分析可能對你有幫助。

如果在這些還沒有改善的情況下，應(yīng)當去想一想，硬件是否足夠、配置是否合理等等系統(tǒng)級別的問題。

五、

似乎在說瓶頸在于tomcat并發(fā)承載能力不夠，但為什么tomcat只能承擔單機200個并發(fā)?當并發(fā)急劇上升的時候，tomcat在執(zhí)行動態(tài)請求的時候，瓶頸在哪里?是哪部分程序，或者哪個環(huán)節(jié)首先導(dǎo)致tomcat失去響應(yīng)的?在davexin描述的刀片硬件上面，tomcat上面如果跑的僅僅是較簡單的jsp頁面，在采用BEA JRockit JVM的情況下，500個并發(fā)也可以達到。

我的推測是瓶頸還是出在EJB遠程方法調(diào)用上!

tomcat上面的java應(yīng)用要通過EJB遠程方法調(diào)用，來訪問weblogic上面的無狀態(tài)SessionBean，這樣的遠程方法調(diào)用一般都在100ms~500ms級別，或者更多。而如果沒有遠程方法調(diào)用，即使大量采用spring的動態(tài)反射，一次完整的web請求處理在本地JVM內(nèi)部的完成時間一般也不過20ms而已。一次web請求需要過長的執(zhí)行時間，就會導(dǎo)致servlet線程被占用更多的時間，從而無法及時響應(yīng)更多的后續(xù)請求。

如果這個推測是成立的話，那么我的建議就是既然你沒有用到分布式事務(wù)，那么就干脆去掉EJB。weblogic也可以全部撤掉，業(yè)務(wù)層使用spring取代EJB，不要搞分布式架構(gòu)，在每個tomcat實例上面部署一個完整的分層結(jié)構(gòu)。

另外在高并發(fā)情況下，apache處理靜態(tài)資源也很耗內(nèi)存和CPU，可以考慮用輕量級web server如lighttpd/litespeed/nginx取代之。

六、

tomcat之所以并發(fā)低很可能是由于remote session bean造成的，remote session bean又一次被濫用了，在樓主的這種業(yè)務(wù)情況下，web層和service層根本不需要分開，象樓主這樣分開帶來就是一訪問業(yè)務(wù)層就帶來長時間的遠程請求，確實導(dǎo)致tomcat上servlet資源釋放的問題。那么remote session bean應(yīng)該被用在什么地方呢，without ejb上有寫到金融系統(tǒng)常用ejb。我把他的這句話延伸一下，也就是說當業(yè)務(wù)的運行時間遠超過遠程調(diào)用的時間時，我們就可以用remote session bean來把這個業(yè)務(wù)分離出去。而樓主的系統(tǒng)中沒有這種業(yè)務(wù)情況。所以使用remote session bean應(yīng)該來說是一個錯誤的選擇，不過這個錯誤的選擇帶來的危害被大量的硬件所掩蓋，帶來的是成本的提高。而性能上還不如slsb。

所以我覺得如果要改架構(gòu)較便捷的方法是使用slsb，把remote session bean去掉。這樣改造的成本比較低，如果換成spring+hibernate成本就高得多了。也就是說可以struts+Bean+DAO+helper，然后把weblogic作cluster，任意一個node上都部署相同的應(yīng)用。也就是水平擴展，理論上來講當性能不滿足要求時添加node就行了，如果能做成農(nóng)場就更加方便了。當然即使非農(nóng)場也沒有關(guān)系，可以用現(xiàn)在在使用的stick分發(fā)。這樣的改造之所以方便是因為把remote session bean改成slsb是很容易的，而且團隊里的人估計對ejb都更加熟悉一點，成本會比較低一點

七、

近段時間正在做購買新硬件和新軟件的預(yù)算，公司高層準備買weblogic10和oracle 10g，所以請了bea公司的人員和我一塊做測試，經(jīng)過近幾天的測試，測試一下新的系統(tǒng)指標1萬個并發(fā)，需要多少軟件和多少硬件能夠支撐，已經(jīng)測試了不同的組合方式，有了不同的結(jié)果，分別如下：

1。1臺weblogic10 能支持900個用戶并發(fā)(沒有用ejb)，平均響應(yīng)時間 10秒。

2。1臺weblogic10 Express(相當于1臺tomcat，用于發(fā)布jsp應(yīng)用)加1臺weblogic10(發(fā)布ejb應(yīng)用)，能支持1000個并發(fā)用戶，平均響應(yīng)時間9秒，由于本人使用的loadRunner較多支持1000個web并發(fā)，雖然此時weblogic沒有任何錯誤，但是沒辦法再向上壓用戶，所以不知道較高能支撐多少個并發(fā)用戶，很遺憾。

3。1臺weblogic8， 能支持900個用戶并發(fā)(沒有用ejb)，平均響應(yīng)時間 11秒。但是沒有weblogic10在同樣時間內(nèi)處理的交易數(shù)量多?？梢耘卸ㄐ阅懿荒躻eblogic10。

4。1臺tomcat4.1加1臺weblogic8，只能支持350個并發(fā)用戶，tomcat就連結(jié)超時，說明此種結(jié)構(gòu)瓶頸在tomcat。北京網(wǎng)站建設(shè)創(chuàng)新互聯(lián)有的不僅僅是8年的網(wǎng)站建設(shè)經(jīng)驗，更多的是站在用戶的角度去設(shè)計網(wǎng)站，符合大多數(shù)人的使用習慣，做更好的用戶體驗！

網(wǎng)站名稱：建設(shè)大型網(wǎng)站要考慮數(shù)據(jù)庫壓力和服務(wù)器負載
網(wǎng)站路徑：http://www.rwnh.cn/news6/108356.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供用戶體驗、微信公眾號、網(wǎng)站建設(shè)、自適應(yīng)網(wǎng)站、定制網(wǎng)站、全網(wǎng)營銷推廣

廣告

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