一、
1、數(shù)據(jù)庫壓力問題
所有的壓力最終都會反映到數(shù)據(jù)庫方面，一定要對數(shù)據(jù)庫有一個(gè)整體的規(guī)劃。
可以按照業(yè)務(wù)、區(qū)域等等特性對數(shù)據(jù)庫進(jìn)行配置，可以考慮分庫、使用rac、分區(qū)、分表等等策略，確保數(shù)據(jù)庫能正常的進(jìn)行交易。
2、事務(wù)問題
你采用了兩種類型數(shù)據(jù)庫，一個(gè)SQLServer、一個(gè)oracle，如果一個(gè)交易需要在兩個(gè)數(shù)據(jù)庫中操作，那么必須考慮到分布式事務(wù)，你應(yīng)該仔細(xì)的設(shè)計(jì)你的系統(tǒng)，來避免使用分布式事務(wù)，以避免分布式事務(wù)帶來更多的數(shù)據(jù)庫壓力和其它問題。推薦你采用延遲提交的策略(并不保證數(shù)據(jù)的完整)，來避免分布式事務(wù)的問題，畢竟commit失敗的幾率很低。（某個(gè)超大型系統(tǒng)，有3套數(shù)據(jù)庫，也是采用的延遲提交策略，避免分布式事務(wù)帶來的對數(shù)據(jù)庫過大的壓力）。
看到了你在應(yīng)用前端(weblogicEJB)采用了F5，我個(gè)人不是很贊同這個(gè)方案，雖然F5是一個(gè)好的L4產(chǎn)品，也能基于第7層做負(fù)載均衡和容災(zāi)。但是一個(gè)有事務(wù)交易的EJB，如果采用了這種方案，把不需要使用分布式事務(wù)的交易變成了分布式交易，試想，一個(gè)web如果在一個(gè)請求中，訪問了后端兩個(gè)EJB，那么L4就會有可能把請求分發(fā)到不同的服務(wù)器上，沒有對事務(wù)維持在一個(gè)服務(wù)器中，就不能使用本地事務(wù)。同樣，一個(gè)web，訪問后端一個(gè)請求，這個(gè)請求中需要3個(gè)EJB，那么極有可能把這3個(gè)請求分發(fā)到不同的服務(wù)器，又造成了分布式事務(wù)。weblogic是一個(gè)好的J2EE產(chǎn)品，對這種有事務(wù)關(guān)聯(lián)的負(fù)載均衡，它會優(yōu)先考慮采用一個(gè)服務(wù)器里面的應(yīng)用，這樣就采用了本地事務(wù)，提高了響應(yīng)速度，減小了分布式事務(wù)對應(yīng)用和數(shù)據(jù)庫的壓力。
3、web的優(yōu)化
我個(gè)人認(rèn)為，一個(gè)商業(yè)的應(yīng)用，硬件的投資可能不是主要的瓶頸，往往可維護(hù)性，可擴(kuò)展性是最主要的問題。
沒有必要采用不成熟的方案，要更多的使用成熟的方案，將靜態(tài)、圖片獨(dú)立使用不同的服務(wù)器，對于常態(tài)的靜態(tài)文件，采用E-TAG或者客戶端緩存，google很多就是這樣干的。對于熱點(diǎn)的功能，考慮使用完全裝載到內(nèi)存，保證絕對的響應(yīng)速度，對于需要頻繁訪問的熱點(diǎn)數(shù)據(jù)，采用集中緩存(多個(gè)可以采用負(fù)載均衡)，減輕數(shù)據(jù)庫的壓力，比如：很多配置信息，操作員信息等等。
對了，對于幾乎除二進(jìn)制文件，都應(yīng)該在L4上配置基于硬件的壓縮方案，減少網(wǎng)絡(luò)的流量。提高用戶使用的感知。
4、網(wǎng)絡(luò)問題
你不可能要求所有的使用人員，都和你的服務(wù)器在一個(gè)運(yùn)營商的網(wǎng)絡(luò)內(nèi)，可以考慮采用鏡像、多路網(wǎng)絡(luò)接入、基于DNS的負(fù)載均衡。如果有足夠的投資，可以采用CDN(內(nèi)容分發(fā)網(wǎng))，減輕你的服務(wù)器壓力。
二、F5的負(fù)載均衡 是必不可少的，他的每秒點(diǎn)擊量能達(dá)到將近30萬，并且它有會話的粘性，只要是同一個(gè)ip發(fā)過來的請求，它就會把它分到同一臺機(jī)器的，不用擔(dān)心分發(fā)錯(cuò)誤的?，F(xiàn)在的問題是apache和tomcat的能力不平衡，動態(tài)的內(nèi)容壓力太大，不是數(shù)據(jù)庫的壓力，我們的數(shù)據(jù)庫
oracle是RAC群集。性能很好
三、tomcat為什么死掉？當(dāng)時(shí)CPU或者內(nèi)存的占用率是多少？看看其中JVM占用了多少？有沒有OOM的錯(cuò)誤？不可能20臺tomcat只能支撐5000的并發(fā)。。。以前做過單臺的resin峰值到3K都是綽綽有余的。。。把緩存做好，減少動態(tài)查詢
四、
1、F5的使用
F5不光可以做web的負(fù)載均衡，也可以做基于第4層的負(fù)載均衡。
比如：銀行接口，大部分基于socket通訊的，就可以在前面架設(shè)一套F5設(shè)備，將請求分發(fā)到不同的服務(wù)器上。
大部分使用F5都是在web層次上，如果使用基于源IP地址的策略，有很多客戶端都是基于代理服務(wù)器，這個(gè)時(shí)候源IP地址是一樣的，其實(shí)并沒有把這些用戶給分發(fā)到不同的服務(wù)器上，建議采用基于cookieinsert的方式，采用cookie的會話保持策略，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ā)起的請求都是什么響應(yīng)狀態(tài)，如果看到很多304請求狀態(tài)，你需要優(yōu)化你的url緩存，看一下每個(gè)url的耗費(fèi)時(shí)間，仔細(xì)針對比較慢的進(jìn)行調(diào)優(yōu)；對于tomcat或者weblogic，在高并發(fā)的情況下，用kill -3<PID>，獲得ThreadDump(HeapDump需要特殊的設(shè)置)，看一下在高并發(fā)下，jvm的線程到底在干什么，仔細(xì)的分析可能對你有幫助。
如果在這些還沒有改善的情況下，應(yīng)當(dāng)去想一想，硬件是否足夠、配置是否合理等等系統(tǒng)級別的問題。
五、似乎在說瓶頸在于tomcat并發(fā)承載能力不夠，但為什么tomcat只能承擔(dān)單機(jī)200個(gè)并發(fā)？當(dāng)并發(fā)急劇上升的時(shí)候，tomcat在執(zhí)行動態(tài)請求的時(shí)候，瓶頸在哪里？是哪部分程序，或者哪個(gè)環(huán)節(jié)首先導(dǎo)致tomcat失去響應(yīng)的？在davexin描述的刀片硬件上面，tomcat上面如果跑的僅僅是最簡單的jsp頁面，在采用BEA JRockit JVM的情況下，500個(gè)并發(fā)也可以達(dá)到。
我的推測是瓶頸還是出在EJB遠(yuǎn)程方法調(diào)用上！
tomcat上面的java應(yīng)用要通過EJB遠(yuǎn)程方法調(diào)用，來訪問weblogic上面的無狀態(tài)SessionBean，這樣的遠(yuǎn)程方法調(diào)用一般都在100ms~500ms級別，或者更多。而如果沒有遠(yuǎn)程方法調(diào)用，即使大量采用spring的動態(tài)反射，一次完整的web請求處理在本地JVM內(nèi)部的完成時(shí)間一般也不過20ms而已。一次web請求需要過長的執(zhí)行時(shí)間，就會導(dǎo)致servlet線程被占用更多的時(shí)間，從而無法及時(shí)響應(yīng)更多的后續(xù)請求。
如果這個(gè)推測是成立的話，那么我的建議就是既然你沒有用到分布式事務(wù)，那么就干脆去掉EJB。weblogic也可以全部撤掉，業(yè)務(wù)層使用spring取代EJB，不要搞分布式架構(gòu)，在每個(gè)tomcat實(shí)例上面部署一個(gè)完整的分層結(jié)構(gòu)。
另外在高并發(fā)情況下，apache處理靜態(tài)資源也很耗內(nèi)存和CPU，可以考慮用輕量級web server如lighttpd/litespeed/nginx取代之。
六、tomcat之所以并發(fā)低很可能是由于remote session bean造成的，remote sessionbean又一次被濫用了，在樓主的這種業(yè)務(wù)情況下，web層和service層根本不需要分開，象樓主這樣分開帶來就是一訪問業(yè)務(wù)層就帶來長時(shí)間的遠(yuǎn)程請求，確實(shí)導(dǎo)致tomcat上servlet資源釋放的問題。那么remote session bean應(yīng)該被用在什么地方呢，withoutejb上有寫到金融系統(tǒng)常用ejb。我把他的這句話延伸一下，也就是說當(dāng)業(yè)務(wù)的運(yùn)行時(shí)間遠(yuǎn)超過遠(yuǎn)程調(diào)用的時(shí)間時(shí)，我們就可以用remotesession bean來把這個(gè)業(yè)務(wù)分離出去。而樓主的系統(tǒng)中沒有這種業(yè)務(wù)情況。所以使用remote sessionbean應(yīng)該來說是一個(gè)錯(cuò)誤的選擇，不過這個(gè)錯(cuò)誤的選擇帶來的危害被大量的硬件所掩蓋，帶來的是成本的提高。而性能上還不如slsb。
所以我覺得如果要改架構(gòu)最便捷的方法是使用slsb，把remote sessionbean去掉。這樣改造的成本比較低，如果換成spring+hibernate成本就高得多了。也就是說可以struts+Bean+DAO+helper，然后把weblogic作cluster，任意一個(gè)node上都部署相同的應(yīng)用。也就是水平擴(kuò)展，理論上來講當(dāng)性能不滿足要求時(shí)添加node就行了，如果能做成農(nóng)場就更加方便了。當(dāng)然即使非農(nóng)場也沒有關(guān)系，可以用現(xiàn)在在使用的stick分發(fā)。這樣的改造之所以方便是因?yàn)榘裷emote session bean改成slsb是很容易的，而且團(tuán)隊(duì)里的人估計(jì)對ejb都更加熟悉一點(diǎn)，成本會比較低一點(diǎn)
七、
近段時(shí)間正在做購買新硬件和新軟件的預(yù)算，公司高層準(zhǔn)備買weblogic10和oracle10g，所以請了bea公司的人員和我一塊做測試，經(jīng)過近幾天的測試，測試一下新的系統(tǒng)指標(biāo)1萬個(gè)并發(fā)，需要多少軟件和多少硬件能夠支撐，已經(jīng)測試了不同的組合方式，有了不同的結(jié)果，分別如下：
1。1臺weblogic10 能支持900個(gè)用戶并發(fā)（沒有用ejb），平均響應(yīng)時(shí)間 10秒。
2。1臺weblogic10Express（相當(dāng)于1臺tomcat，用于發(fā)布jsp應(yīng)用）加1臺weblogic10（發(fā)布ejb應(yīng)用），能支持1000個(gè)并發(fā)用戶，平均響應(yīng)時(shí)間9秒，由于本人使用的loadRunner最多支持1000個(gè)web并發(fā)，雖然此時(shí)weblogic沒有任何錯(cuò)誤，但是沒辦法再向上壓用戶，所以不知道最高能支撐多少個(gè)并發(fā)用戶，很遺憾。
3。1臺weblogic8， 能支持900個(gè)用戶并發(fā)（沒有用ejb），平均響應(yīng)時(shí)間 11秒。但是沒有weblogic10在同樣時(shí)間內(nèi)處理的交易數(shù)量多?？梢耘卸ㄐ阅懿荒躻eblogic10。
4。1臺tomcat4.1加1臺weblogic8，只能支持350個(gè)并發(fā)用戶，tomcat就連結(jié)超時(shí)，說明此種結(jié)構(gòu)瓶頸在tomcat。
5。1臺tomcat6.14加1臺weblogic8，還不如方案4，tomcat結(jié)超時(shí)更多，說明此種結(jié)構(gòu)瓶頸在tomcat。由于還沒有看tomcat6.14的調(diào)優(yōu)資料。所以還請高手給建議。
6。1臺tomcat4.1加1臺weblogic10，性能同樣不佳，問題出現(xiàn)在tomcat性能跟不上。
7。1臺tomcat6.14加1臺weblogic10，性能同樣不佳，問題出現(xiàn)在tomcat性能跟不上。
明天還要做一個(gè)weblogic10 cluster測試，等有了測試結(jié)果，再根大家交流。
以上測試機(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公司人員建議購買16-20cpu的licens。機(jī)器購買4cpu + 8G內(nèi)存機(jī)器4-6臺。前端tomcat增加到50臺。
由于根據(jù)以前的宕機(jī)記錄，主要表現(xiàn)在tomcat層，個(gè)別高峰時(shí)候也出現(xiàn)在F5。故不敢輕易的舍棄無狀態(tài)sessionbean。由于tomcat做了大部分的業(yè)務(wù)，只有需要數(shù)據(jù)庫的時(shí)候才調(diào)用weblogic中間件，由于weblogic的價(jià)格還是比較昂貴的，公司以前購買的weblogiclicens數(shù)量限制。所以還不能把所有的tomcat換成weblogic。如果有20臺weblogic的licens，我也就不擔(dān)心1萬個(gè)并發(fā)了。
八、
坦白說我還從來沒有聽說過大規(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)部做過性能對比評測，JBoss4 vs WebLogic9，在web容器一項(xiàng)的評測當(dāng)中，JBoss4勝出。這個(gè)結(jié)果并不令人感到意外，因?yàn)閣eb容器的性能說到底無非就是Servlet線程調(diào)度能力而已，Tomcat不像WebLogic那樣附加n多管理功能，跑得快很正常。這一點(diǎn)你只要對比測試一下WebLogic的數(shù)據(jù)庫連接池和C3P0連接池的性能也會發(fā)現(xiàn)類似的結(jié)論，C3P0可要比WebLogic的連接池快好幾倍了。這不是說WebLogic性能不好，只不過weblogic要實(shí)現(xiàn)更多的功能，所以在單一的速度方面就會犧牲很多東西。
以我的經(jīng)驗(yàn)來判斷，使用tomcat5.5以上的版本，配置apr支持，進(jìn)行必要的tuning，使用BEA JRockitJVM的話，在你們目前的刀片上面，支撐500個(gè)并發(fā)完全是可以做到的。結(jié)合你們目前20個(gè)刀片的硬件，那么達(dá)到1萬并發(fā)是沒問題的。當(dāng)然這樣做的前提是必須扔掉EJB，并置web層和業(yè)務(wù)層在同一個(gè)JVM內(nèi)部。
從你上面的發(fā)言來看，你們之所以采用EJB，無非是因?yàn)榻?jīng)費(fèi)有限，無法購買充足的weblogiclicense。所以退而求其次，購買少量的weblogiclicense，專門跑業(yè)務(wù)層服務(wù)器，用SLSB暴露遠(yuǎn)程接口給tomcat調(diào)用。然后部署n十多臺免費(fèi)的tomcat服務(wù)器跑web。為省錢而采用EJB到是一個(gè)很新鮮的事，但實(shí)際上這就是一個(gè)很愚蠢的決定。
weblogic的優(yōu)秀更多的體現(xiàn)在他對于J2EE標(biāo)準(zhǔn)優(yōu)秀的支持，各種復(fù)雜的企業(yè)應(yīng)用場景以及傳統(tǒng)的中間件應(yīng)用的豐富而方便的集成手段上。簡單的來說，就是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)不出有什么能夠超過resin/tomcat的地方，誠然weblogicexpress的web容器穩(wěn)定性要好于tomcat，但沒有互聯(lián)網(wǎng)企業(yè)在大規(guī)模部署tomcat水平群集的時(shí)候，還會為這一點(diǎn)而瘋狂買單購買weblogic license。
所以我個(gè)人很不理解，作為一個(gè)互聯(lián)網(wǎng)公司的CTO，怎么會如此迷信weblogic，因?yàn)槲艺J(rèn)識的互聯(lián)網(wǎng)公司高層，沒有什么人愿意用商業(yè)產(chǎn)品，絕大多數(shù)都是用開源的，我不憚揣測他的背景可能來自傳統(tǒng)企業(yè)應(yīng)用出身的吧，呵呵。
九、
這說明瓶頸還不在EJB遠(yuǎn)程調(diào)用上，但是問題已經(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之間的接口出了問題
上面的帖子其實(shí)我也介紹過了，如果只是單純的作為servlet容器來看，tomcat的性能不應(yīng)該比weblogic差，甚至還要更好，所以你可以這樣來擬定測試方案：
在同樣硬件環(huán)境下對比測試tomcat5.5和weblogic10的servlet容器性能，分別寫幾個(gè)訪問數(shù)據(jù)庫，和不訪問數(shù)據(jù)庫的JSP頁面測試就可以了，并發(fā)從500往上走，看看哪個(gè)throughput更高。記得要調(diào)優(yōu)tomcat5.5，配置apr支持要打開。
如果測試結(jié)果表明tomcat并發(fā)響應(yīng)能力遠(yuǎn)遠(yuǎn)差于weblogic，那就說明你的tomcat配置有很大的問題，好好鉆研tomcat configuration && performance tuning吧；
如果測試結(jié)果表明tomcat并發(fā)響應(yīng)能力與weblogic相當(dāng)，或者差不多，那么很不幸，問題不在tomcat本身，而是出在了tomcat到weblogic的接口上。而tomcat是通過weblogic提供的EJB clientjar去調(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)化
動態(tài)頁面發(fā)布為靜態(tài)頁面？
Cache部分動態(tài)頁面內(nèi)容？
十一、
對于樓主的問題，以及公司的架構(gòu)方案，我認(rèn)為你們?nèi)匀辉诜稿e(cuò)！
誤區(qū)：遇到性能問題的第一件事情就是找硬件和容器的事情!
性能問題的基本上無一例外的都出在寫的程序有問題，滿足不了伸縮性。
好好看看你們的程序吧，不要再給bea打電話了，你得到的建議，基本上都是用不到的。
robin的觀點(diǎn)是對的，我甚至懷疑你們的數(shù)據(jù)庫連接是否有釋放問題的。
增加你們前端的內(nèi)存，多做緩存。hibernate的cache方案不差jdbc對數(shù)據(jù)庫的頻繁使用
html的書寫是否符合w3的規(guī)范
最好在一個(gè)服務(wù)器上部署整個(gè)應(yīng)用！
十二、
淘寶用的weblogic8,他們的web層使用的Turbine，且大量的使用velocity，由于對事務(wù)要求及其苛刻用到了ejb,也用到spring很多其他服務(wù)，訪問數(shù)據(jù)庫使用ibatis，他們對weblogic優(yōu)化到的極致加上外面也架了apache,，在如此高并發(fā)的情況，且高度復(fù)雜的搜索。。。，還能保持如此的響應(yīng)速度，確實(shí)很不錯(cuò)。
淘寶的搜索功能說是在的非常強(qiáng)大，不曉得是不是yahoo中國來人做的，一直覺得很神奇
robbin大哥說的還是很有道理，對于大多數(shù)門戶門戶網(wǎng)站，使用EJB確實(shí)浪費(fèi)，購買weblogic的錢可以購買很多硬件來apache,tomcat負(fù)載均衡遠(yuǎn)遠(yuǎn)勝過于ejb方案的性能。沒有絕對的性能好壞之分，主要還是看你的需求，weblogic永遠(yuǎn)是對于銀行，證券，電信的行業(yè)所準(zhǔn)備，他們所使用的硬件對象也絕對不是刀片，雙路至強(qiáng)的硬件這樣的東東。
十三、
經(jīng)過今天修改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)過測試，并發(fā)人數(shù)是可以達(dá)到像robbin所說的一樣，能夠在600人左右，如果壓到并發(fā)700人，就有15%左右的失敗，雖然在調(diào)整上面參數(shù)之后，并發(fā)人數(shù)上去了，但是在同樣的時(shí)間內(nèi)所完成的事務(wù)數(shù)量下降了10%左右，并且響應(yīng)時(shí)間延遲了1秒左右，但從整體上來說，犧牲一點(diǎn)事務(wù)吞吐量和響應(yīng)時(shí)間，并發(fā)人數(shù)能夠提高500，覺得還是值得的。謝謝robbin的建議。
由于本人使用的loadRunner能支持的獨(dú)立client數(shù)量在100個(gè)，所以沒辦法對ejb進(jìn)行單獨(dú)的壓力測試。因?yàn)槲以趯η岸螒?yīng)用調(diào)用ejb時(shí)，最多并發(fā)用戶已經(jīng)達(dá)到1000個(gè)，但是通過監(jiān)控weblogic10中發(fā)布的ejb應(yīng)用和連接池，發(fā)現(xiàn)ejb應(yīng)用等待數(shù)量為0，但是連接池中最多有60個(gè)活動連接，有7個(gè)連接在等待，因?yàn)榇藭r(shí)設(shè)置的weblogic連接池最大數(shù)量是60，后來對連接池?cái)?shù)量進(jìn)行增大到160個(gè)，再次進(jìn)行測試，發(fā)現(xiàn)性能反而不如把連接池?cái)?shù)量調(diào)為60個(gè)的時(shí)候。問起bea的人，他們也說不清楚原因。
同時(shí)對他們所提供的一種更好的jvm進(jìn)行測試，jvm的名字是 RealTime.發(fā)現(xiàn)性能并沒有太大改善。
我們現(xiàn)在的系統(tǒng)已經(jīng)作了很多的緩存，有全局的，有局部的，都是放到內(nèi)存中的HashMap，靜態(tài)的頁面都是放在apache上的，不過沒有使用 apr， 接下來如果有時(shí)間，會測試一下這個(gè)咚咚，。
che前面是F5負(fù)載均衡器，在apache后面是tomcat，tomcat在公網(wǎng)上，然后通過內(nèi)網(wǎng)網(wǎng)卡訪問weblogic，weblogic才能訪問數(shù)據(jù)庫，tomcat不能直接訪問數(shù)據(jù)庫的，由于以前的網(wǎng)絡(luò)結(jié)構(gòu)的原因，也有安全的原因，公司還有部分服務(wù)器在北京（無線事業(yè)部）和廣州（老系統(tǒng)，以后會逐漸遷移到上海），雖然現(xiàn)在也有其他的安全方案可以把tomcat放在內(nèi)網(wǎng)，去掉weblogic，但是這種改變是需要時(shí)間的，也要考慮平穩(wěn)過渡，所以還請各位理解。至于購買weblogic，公司也是有自己的考慮的。因?yàn)橐郧熬褪沁\(yùn)行在weblogic上的，如果現(xiàn)在不用了，如果出了問題，就很難辦了。
十四、是的，如果調(diào)整參數(shù)，可以達(dá)到并發(fā)人數(shù)達(dá)到1000以上，但是通過對比同樣壓力下的weblogic和tomcat，發(fā)現(xiàn)tomcat的響應(yīng)時(shí)間都比weblogic長，并且tomcat的cpu的占用率達(dá)到45%-60%，而同樣的壓力下weblogic的cpu占用只有3%-5%。內(nèi)存都是2G都用了97%，說明主要差別表現(xiàn)在cpu和相應(yīng)時(shí)間上，我沒有做tomcat1000人并發(fā)測試，但是從以前600人并發(fā)的響應(yīng)時(shí)間判斷，我覺得響應(yīng)時(shí)間可能會超過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ù)量來滿足應(yīng)用需求吧。
十五、
又回到了realtime的定義，并不是很快的意思，而是響應(yīng)時(shí)間是可預(yù)計(jì)的。
而JVM對響應(yīng)時(shí)間可預(yù)計(jì)性的影響，主要表現(xiàn)在
1.線程調(diào)度受操作系統(tǒng)線程調(diào)度的影響
2.垃圾收集引起的暫停
所以jrockit選擇了動態(tài)垃圾收集，以頻繁的收集來換取每次中斷時(shí)間的減少，所以，對吞吐量來說，是反而會下降的。大部分jvm都有吞吐量優(yōu)先，短暫停時(shí)間兩種截然不同的垃圾收集算法。
聯(lián)系客服
