所謂大型網(wǎng)站就是訪問(wèn)量與流量都很大的一些網(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ù)壓力問(wèn)題 所有的壓力最終都會(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ù)問(wèn)題 你采用了兩種類型數(shù)據(jù)庫(kù)，一個(gè)SQL Server、一個(gè)oracle，如果一個(gè)交易需要在兩個(gè)數(shù)據(jù)庫(kù)中操作，那么必須考慮到分布式事務(wù)，你應(yīng)該仔細(xì)的設(shè)計(jì)你的系統(tǒng)，來(lái)避免使用分布式事務(wù)，以避免分布式事務(wù)帶來(lái)更多的數(shù)據(jù)庫(kù)壓力和其它問(wèn)題。推薦你采用延遲提交的策略(并不保證數(shù)據(jù)的完整)，來(lái)避免分布式事務(wù)的問(wèn)題，畢竟commit失敗的幾率很低。（某個(gè)超大型系統(tǒng)，有3套數(shù)據(jù)庫(kù)，也是采用的延遲提交策略，避免分布式事務(wù)帶來(lái)的對(duì)數(shù)據(jù)庫(kù)過(guò)大的壓力）。

看到了你在應(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)求中，訪問(wèn)了后端兩個(gè)EJB，那么L4就會(huì)有可能把請(qǐng)求分發(fā)到不同的服務(wù)器上，沒有對(duì)事務(wù)維持在一個(gè)服務(wù)器中，就不能使用本地事務(wù)。同樣，一個(gè)web，訪問(wèn)后端一個(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ò)展性是最主要的問(wèn)題。

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

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

4、網(wǎng)絡(luò)問(wèn)題 你不可能要求所有的使用人員，都和你的服務(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ā)過(guò)來(lái)的請(qǐng)求，它就會(huì)把它分到同一臺(tái)機(jī)器的，不用 擔(dān)心分發(fā)錯(cuò)誤的�，F(xiàn)在的問(wè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ā)。。。以前做過(guò)單臺(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í)際情況來(lái)設(shè)置。

2、大并發(fā)的問(wèn)題 現(xiàn)在你得到了一個(gè)大概的系統(tǒng)能承受的并發(fā)，但是還達(dá)不到系統(tǒng)的設(shè)計(jì)目標(biāo)。 應(yīng)該從應(yīng)用的角度去分析這個(gè)問(wèn)題，web方面，通過(guò)工具(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 <PID>，獲得ThreadDump(HeapDump需要特殊的設(shè)置)，看一下在高并發(fā)下，jvm的線程到底在干什么，仔細(xì)的分析可能對(duì)你有幫助。

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

五、

似乎在說(shuō)瓶頸在于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)用要通過(guò)EJB遠(yuǎn)程方法調(diào)用，來(lái)訪問(wèn)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í)間一般也不過(guò)20ms而已。一次web請(qǐng)求需要過(guò)長(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層根本不需要分開，象樓主這樣分開帶來(lái)就是一訪問(wèn)業(yè)務(wù)層就帶來(lái)長(zhǎng)時(shí)間的遠(yuǎn)程請(qǐng)求，確實(shí)導(dǎo)致tomcat上servlet資源釋放的問(wèn)題。那么remote session bean應(yīng)該被用在什么地方呢，without ejb上有寫到金融系統(tǒng)常用ejb。我把他的這句話延伸一下，也就是說(shuō)當(dāng)業(yè)務(wù)的運(yùn)行時(shí)間遠(yuǎn)超過(guò)遠(yuǎn)程調(diào)用的時(shí)間時(shí)，我們就可以用remote session bean來(lái)把這個(gè)業(yè)務(wù)分離出去。而樓主的系統(tǒng)中沒有這種業(yè)務(wù)情況。所以使用remote session bean應(yīng)該來(lái)說(shuō)是一個(gè)錯(cuò)誤的選擇，不過(guò)這個(gè)錯(cuò)誤的選擇帶來(lái)的危害被大量的硬件所掩蓋，帶來(lái)的是成本的提高。而性能上還不如slsb。

所以我覺得如果要改架構(gòu)最便捷的方法是使用slsb，把remote session bean去掉。這樣改造的成本比較低，如果換成spring+hibernate成本就高得多了。也就是說(shuō)可以struts+Bean+DAO+helper，然后把weblogic作cluster，任意一個(gè)node上都部署相同的應(yīng)用。也就是水平擴(kuò)展，理論上來(lái)講當(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)過(guò)近幾天的測(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í)，說(shuō)明此種結(jié)構(gòu)瓶頸在tomcat。[CDATA_PAGE]

5。1臺(tái)tomcat6.14加1臺(tái)weblogic8，還不如方案4，tomcat結(jié)超時(shí)更多，說(shuō)明此種結(jié)構(gòu)瓶頸在tomcat。由于還沒有看tomcat6.14的調(diào)優(yōu)資料。所以還請(qǐng)高手給建議。

6。1臺(tái)tomcat4.1加1臺(tái)weblogic10，性能同樣不佳，問(wèn)題出現(xiàn)在tomcat性能跟不上。

7。1臺(tái)tomcat6.14加1臺(tái)weblogic10，性能同樣不佳，問(wèn)題出現(xiàn)在tomcat性能跟不上。

明天還要做一個(gè)weblogic10 cluster測(cè)試，等有了測(cè)試結(jié)果，再根大家交流。

以上測(cè)試機(jī)器都為 linux as4 操作系統(tǒng)，2cpu + 2G內(nèi)存，發(fā)現(xiàn)cpu利用率最高占45%，一般就在10%左右，內(nèi)存可以用到1.5G。 loadRunner機(jī)器為2cpu + 2G內(nèi)存，window server 2003操作系統(tǒng)。

有以上的結(jié)果，bea公司人員建議購(gòu)買16-20cpu的licens。機(jī)器購(gòu)買4cpu + 8G內(nèi)存機(jī)器4-6臺(tái)。前端tomcat增加到50臺(tái)。

由于根據(jù)以前的宕機(jī)記錄，主要表現(xiàn)在tomcat層，個(gè)別高峰時(shí)候也出現(xiàn)在F5。故不敢輕易的舍棄無(wú)狀態(tài)session bean。由于tomcat做了大部分的業(yè)務(wù)，只有需要數(shù)據(jù)庫(kù)的時(shí)候才調(diào)用weblogic中間件，由于weblogic的價(jià)格還是比較昂貴的，公司以前購(gòu)買的weblogic licens數(shù)量限制。所以還不能把所有的tomcat換成weblogic。如果有20臺(tái)weblogic的licens，我也就不擔(dān)心1萬(wàn)個(gè)并發(fā)了。

八、

坦白說(shuō)我還從來(lái)沒有聽說(shuō)過(guò)大規(guī)�；ヂ�(lián)網(wǎng)應(yīng)用使用EJB的先例。為什么大規(guī)�；ヂ�(lián)網(wǎng)應(yīng)用不能用EJB，其實(shí)就是因?yàn)镋JB性能太差，用了EJB幾乎必然出現(xiàn)性能障礙。阿里巴巴和淘寶網(wǎng)那是每天多少億PV的電子商務(wù)網(wǎng)站了，其實(shí)也就是用JBoss而已，而且也只是用其web容器(JBoss的web容器就是tomcat)，所以本質(zhì)上還是在用tomcat。

今年年初，RedHat在深圳的HW大客戶在內(nèi)部做過(guò)性能對(duì)比評(píng)測(cè)，JBoss4 vs WebLogic 9，在web容器一項(xiàng)的評(píng)測(cè)當(dāng)中，JBoss4勝出。這個(gè)結(jié)果并不令人感到意外，因?yàn)閣eb容器的性能說(shuō)到底無(wú)非就是Servlet線程調(diào)度能力而已，Tomcat不像WebLogic那樣附加n多管理功能，跑得快很正常。這一點(diǎn)你只要對(duì)比測(cè)試一下WebLogic的數(shù)據(jù)庫(kù)連接池和C3P0連接池的性能也會(huì)發(fā)現(xiàn)類似的結(jié)論，C3P0可要比WebLogic的連接池快好幾倍了。這不是說(shuō)WebLogic性能不好，只不過(guò)weblogic要實(shí)現(xiàn)更多的功能，所以在單一的速度方面就會(huì)犧牲很多東西。

以我的經(jīng)驗(yàn)來(lái)判斷，使用tomcat5.5以上的版本，配置apr支持，進(jìn)行必要的tuning，使用BEA JRockit JVM的話，在你們目前的刀片上面，支撐500個(gè)并發(fā)完全是可以做到的。結(jié)合你們目前20個(gè)刀片的硬件，那么達(dá)到1萬(wàn)并發(fā)是沒問(wèn)題的。當(dāng)然這樣做的前提是必須扔掉EJB，并置web層和業(yè)務(wù)層在同一個(gè)JVM內(nèi)部。

從你上面的發(fā)言來(lái)看，你們之所以采用EJB，無(wú)非是因?yàn)榻?jīng)費(fèi)有限，無(wú)法購(gòu)買充足的weblogic license。所以退而求其次，購(gòu)買少量的weblogic license，專門跑業(yè)務(wù)層服務(wù)器，用SLSB暴露遠(yuǎn)程接口給tomcat調(diào)用。然后部署n十多臺(tái)免費(fèi)的tomcat服務(wù)器跑web。為省錢而采用EJB到是一個(gè)很新鮮的事，但實(shí)際上這就是一個(gè)很愚蠢的決定。

weblogic的優(yōu)秀更多的體現(xiàn)在他對(duì)于J2EE標(biāo)準(zhǔn)優(yōu)秀的支持，各種復(fù)雜的企業(yè)應(yīng)用場(chǎng)景以及傳統(tǒng)的中間件應(yīng)用的豐富而方便的集成手段上。簡(jiǎn)單的來(lái)說(shuō)，就是weblogic/websphere是企業(yè)應(yīng)用的首選，特別是強(qiáng)調(diào)事務(wù)的企業(yè)應(yīng)用，例如金融，電信計(jì)費(fèi)。但在互聯(lián)網(wǎng)應(yīng)用方面，weblogic/websphere根本就體現(xiàn)不出有什么能夠超過(guò)resin/tomcat的地方，誠(chéng)然weblogic express的web容器穩(wěn)定性要好于tomcat，但沒有互聯(lián)網(wǎng)企業(yè)在大規(guī)模部署tomcat水平群集的時(shí)候，還會(huì)為這一點(diǎn)而瘋狂買單購(gòu)買weblogic license。

所以我個(gè)人很不理解，作為一個(gè)互聯(lián)網(wǎng)公司的CTO，怎么會(huì)如此迷信weblogic，因?yàn)槲艺J(rèn)識(shí)的互聯(lián)網(wǎng)公司高層，沒有什么人愿意用商業(yè)產(chǎn)品，絕大多數(shù)都是用開源的，我不憚揣測(cè)他的背景可能來(lái)自傳統(tǒng)企業(yè)應(yīng)用出身的吧，呵呵。

九、

這說(shuō)明瓶頸還不在EJB遠(yuǎn)程調(diào)用上，但是問(wèn)題已經(jīng)逐漸清楚了。為什么weblogic充當(dāng)web容器發(fā)起遠(yuǎn)程EJB調(diào)用的時(shí)候可以支撐1000個(gè)并發(fā)，但是tomcat只能到350個(gè)？只有兩個(gè)可能的原因：

1、你的tomcat沒有配置好，嚴(yán)重影響了性能表現(xiàn) 2、tomcat和weblogic之間的接口出了問(wèn)題

上面的帖子其實(shí)我也介紹過(guò)了，如果只是單純的作為servlet容器來(lái)看，tomcat的性能不應(yīng)該比weblogic差，甚至還要更好，所以你可以這樣來(lái)擬定測(cè)試方案：

在同樣硬件環(huán)境下對(duì)比測(cè)試tomcat5.5和weblogic10的servlet容器性能，分別寫幾個(gè)訪問(wèn)數(shù)據(jù)庫(kù)，和不訪問(wèn)數(shù)據(jù)庫(kù)的JSP頁(yè)面測(cè)試就可以了，并發(fā)從500往上走，看看哪個(gè)throughput更高。記得要調(diào)優(yōu)tomcat5.5，配置apr支持要打開。

如果測(cè)試結(jié)果表明tomcat并發(fā)響應(yīng)能力遠(yuǎn)遠(yuǎn)差于weblogic，那就說(shuō)明你的tomcat配置有很大的問(wèn)題，好好鉆研tomcat configuration && performance tuning吧；

如果測(cè)試結(jié)果表明tomcat并發(fā)響應(yīng)能力與weblogic相當(dāng)，或者差不多，那么很不幸，問(wèn)題不在tomcat本身，而是出在了tomcat到weblogic的接口上。而tomcat是通過(guò)weblogic提供的EJB client jar去調(diào)用weblogic的EJB的，那你只好咨詢BEA去尋求解決方案了。

十、

1.基礎(chǔ)配置優(yōu)化 tomcat 6？ tomcat參數(shù)調(diào)優(yōu)? JRockit JVM? JVM參數(shù)調(diào)優(yōu)？ Apache+Squid 處理靜態(tài)內(nèi)容？

2.業(yè)務(wù)層優(yōu)化 部分功能本地化，而不調(diào)remote session bean? 異步提交操作,JMS？ cache熱點(diǎn)數(shù)據(jù)？

3.展示層優(yōu)化 動(dòng)態(tài)頁(yè)面發(fā)布為靜態(tài)頁(yè)面？ Cache部分動(dòng)態(tài)頁(yè)面內(nèi)容？

十一、

對(duì)于樓主的問(wèn)題，以及公司的架構(gòu)方案，我認(rèn)為你們?nèi)匀辉诜稿e(cuò)！ 誤區(qū)：遇到性能問(wèn)題的第一件事情就是找硬件和容器的事情! 性能問(wèn)題的基本上無(wú)一例外的都出在寫的程序有問(wèn)題，滿足不了伸縮性。 好好看看你們的程序吧，不要再給bea打電話了，你得到的建議，基本上都是用不到的。 robin的觀點(diǎn)是對(duì)的，我甚至懷疑你們的數(shù)據(jù)庫(kù)連接是否有釋放問(wèn)題的。 增加你們前端的內(nèi)存，多做緩存。hibernate的cache方案不差jdbc對(duì)數(shù)據(jù)庫(kù)的頻繁使用 html的書寫是否符合w3的規(guī)范

最好在一個(gè)服務(wù)器上部署整個(gè)應(yīng)用！

十二、

淘寶用的weblogic8,他們的web層使用的Turbine，且大量的使用velocity，由于對(duì)事務(wù)要求及其苛刻用到了ejb,也用到spring很多其他服務(wù)，訪問(wèn)數(shù)據(jù)庫(kù)使用ibatis，他們對(duì)weblogic優(yōu)化到的極致加上外面也架了apache,，在如此高并發(fā)的情況，且高度復(fù)雜的搜索。。。，還能保持如此的響應(yīng)速度，確實(shí)很不錯(cuò)。

淘寶的搜索功能說(shuō)是在的非常強(qiáng)大，不曉得是不是yahoo中國(guó)來(lái)人做的，一直覺得很神奇

robbin大哥說(shuō)的還是很有道理，對(duì)于大多數(shù)門戶門戶網(wǎng)站，使用EJB確實(shí)浪費(fèi)，購(gòu)買weblogic的錢可以購(gòu)買很多硬件來(lái)apache,tomcat負(fù)載均衡遠(yuǎn)遠(yuǎn)勝過(guò)于ejb方案的性能。沒有絕對(duì)的性能好壞之分，主要還是看你的需求，weblogic永遠(yuǎn)是對(duì)于銀行，證券，電信的行業(yè)所準(zhǔn)備，他們所使用的硬件對(duì)象也絕對(duì)不是刀片，雙路至強(qiáng)的硬件這樣的東東。

十三、

經(jīng)過(guò)今天修改tomcat的參數(shù)，修改如下： <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080" enableLookups="false" redirectPort="8443" acceptCount="500" maxProcessors="500" minProcessors="500" maxSpareProcessors="200" connectionTimeout="20000" useURIValidationHack="false" disableUploadTimeout="true" /> 經(jīng)過(guò)測(cè)試，并發(fā)人數(shù)是可以達(dá)到像robbin所說(shuō)的一樣，能夠在600人左右，如果壓到并發(fā)700人，就有15%左右的失敗，雖然在調(diào)整上面參數(shù)之后，并發(fā)人數(shù)上去了，但是在同樣的時(shí)間內(nèi)所完成的事務(wù)數(shù)量下降了10%左右，并且響應(yīng)時(shí)間延遲了1秒左右，但從整體上來(lái)說(shuō)，犧牲一點(diǎn)事務(wù)吞吐量和響應(yīng)時(shí)間，并發(fā)人數(shù)能夠提高500，覺得還是值得的。謝謝robbin的建議。

由于本人使用的loadRunner 能支持的獨(dú)立client數(shù)量在100個(gè)，所以沒辦法對(duì)ejb進(jìn)行單獨(dú)的壓力測(cè)試。因?yàn)槲以趯?duì)前段應(yīng)用調(diào)用ejb時(shí)，最多并發(fā)用戶已經(jīng)達(dá)到1000個(gè)，但是通過(guò)監(jiān)控weblogic10中發(fā)布的ejb應(yīng)用和連接池，發(fā)現(xiàn)ejb應(yīng)用等待數(shù)量為0，但是連接池中最多有60個(gè)活動(dòng)連接，有7個(gè)連接在等待，因?yàn)榇藭r(shí)設(shè)置的weblogic連接池最大數(shù)量是60，后來(lái)對(duì)連接池?cái)?shù)量進(jìn)行增大到160個(gè)，再次進(jìn)行測(cè)試，發(fā)現(xiàn)性能反而不如把連接池?cái)?shù)量調(diào)為60個(gè)的時(shí)候。問(wèn)起bea的人，他們也說(shuō)不清楚原因。

同時(shí)對(duì)他們所提供的一種更好的jvm進(jìn)行測(cè)試，jvm的名字是 RealTime.發(fā)現(xiàn)性能并沒有太大改善。 我們現(xiàn)在的系統(tǒng)已經(jīng)作了很多的緩存，有全局的，有局部的，都是放到內(nèi)存中的HashMap，靜態(tài)的頁(yè)面都是放在apache上的，不過(guò)沒有使用 apr， 接下來(lái)如果有時(shí)間，會(huì)測(cè)試一下這個(gè)咚咚。

che前面是F5負(fù)載均衡器，在apache后面是tomcat，tomcat在公網(wǎng)上，然后通過(guò)內(nèi)網(wǎng)網(wǎng)卡訪問(wèn)weblogic，weblogic才能訪問(wèn)數(shù)據(jù)庫(kù)，tomcat不能直接訪問(wèn)數(shù)據(jù)庫(kù)的，由于以前的網(wǎng)絡(luò)結(jié)構(gòu)的原因，也有安全的原因，公司還有部分服務(wù)器在北京（無(wú)線事業(yè)部）和廣州（老系統(tǒng)，以后會(huì)逐漸遷移到上海），雖然現(xiàn)在也有其他的安全方案可以把tomcat放在內(nèi)網(wǎng)，去掉weblogic，但是這種改變是需要時(shí)間的，也要考慮平穩(wěn)過(guò)渡，所以還請(qǐng)各位理解。至于購(gòu)買weblogic，公司也是有自己的考慮的。因?yàn)橐郧熬褪沁\(yùn)行在weblogic上的，如果現(xiàn)在不用了，如果出了問(wèn)題，就很難辦了。

十四、

是的，如果調(diào)整參數(shù)，可以達(dá)到并發(fā)人數(shù)達(dá)到1000以上，但是通過(guò)對(duì)比同樣壓力下的weblogic和tomcat，發(fā)現(xiàn)tomcat的響應(yīng)時(shí)間都比weblogic長(zhǎng)，并且tomcat的cpu的占用率達(dá)到45%-60%，而同樣的壓力下weblogic的cpu占用只有3%-5%。內(nèi)存都是2G都用了97%，說(shuō)明主要差別表現(xiàn)在cpu和相應(yīng)時(shí)間上，我沒有做tomcat 1000人并發(fā)測(cè)試，但是從以前600人并發(fā)的響應(yīng)時(shí)間判斷，我覺得響應(yīng)時(shí)間可能會(huì)超過(guò)15秒。所以從綜合各方面性能指標(biāo)考慮，我覺得要找出一個(gè)響應(yīng)時(shí)間，并發(fā)人數(shù)，完成交易數(shù)量3方面考慮折中，找出一個(gè)滿足應(yīng)用響應(yīng)時(shí)間和并發(fā)用戶的折中吧，如果是并發(fā)交易量比較大的應(yīng)用，我想應(yīng)該減少并發(fā)用戶，提高單位時(shí)間內(nèi)交易數(shù)量來(lái)滿足應(yīng)用需求吧。

十五、

又回到了realtime的定義，并不是很快的意思，而是響應(yīng)時(shí)間是可預(yù)計(jì)的。

而JVM對(duì)響應(yīng)時(shí)間可預(yù)計(jì)性的影響，主要表現(xiàn)在 1.線程調(diào)度受操作系統(tǒng)線程調(diào)度的影響 2.垃圾收集引起的暫停

所以jrockit選擇了動(dòng)態(tài)垃圾收集，以頻繁的收集來(lái)?yè)Q取每次中斷時(shí)間的減少，所以，對(duì)吞吐量來(lái)說(shuō)，是反而會(huì)下降的。大部分jvm都有吞吐量?jī)?yōu)先，短暫停時(shí)間兩種截然不同的垃圾收集算法。