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

一、

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

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

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

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

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

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

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

二、

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

三、

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

四、

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

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

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

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

五、

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

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

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

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

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

六、

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

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

七、

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

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

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

3。1臺(tái)weblogic8， 能支持900個(gè)用戶并發(fā)(沒有用ejb)，平均響應(yīng)時(shí)間 11秒。但是沒有weblogic10在同樣時(shí)間內(nèi)處理的交易數(shù)量多。可以判定性能不能weblogic10。

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

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

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

廣告

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