所謂大型網站就是訪問量與流量都很大的一些網站，因此在建站初期就要考慮好當流量達到某一級別是是否可以支撐網站繼續正常運營下去。其中主要考慮的方面有幾點：數據庫壓力，網頁優化，服務器負載。
一、
1、數據庫壓力問題 所有的壓力最終都會反映到數據庫方面，一定要對數據庫有一個整體的規劃。 可以按照業務、區域等等特性對數據庫進行配置，可以考慮分庫、使用rac、分區、分表等等策略，確保數據庫能正常的進行交易。
2、事務問題 你採用了兩種類型數據庫，一個SQL Server、一個oracle，如果一個交易需要在兩個數據庫中操作，那麼必須考慮到分佈式事務，你應該仔細的設計你的系統，來避免使用分佈式事務，以避免分佈式事務帶來更多的數據庫壓力和其它問題。推薦你採用延遲提交的策略(並不保證數據的完整)，來避免分佈式事務的問題，畢竟commit失敗的機率很低。(某個超大型系統，有3套數據庫，也是採用的延遲提交策略，避免分佈式事務帶來的對數據庫過大的壓力)。
看到了你在應用前端(weblogic EJB)採用了F5，我個人不是很贊同這個方案，雖然F5是一個好的L4產品，也能基於第7層做負載均衡和容災。但是一個有事務交易的EJB，如果採用了這種方案，把不需要使用分佈式事務的交易變成了分佈式交易，試想，一個web如果在一個請求中，訪問了後端兩個EJB，那麼L4就會有可能把請求分發到不同的服務器上，沒有對事務維持在一個服務器中，就不能使用本地事務。同樣，一個web，訪問後端一個請求，這個請求中需要3個EJB，那麼極有可能把這3個請求分發到不同的服務器，又造成了分佈式事務。weblogic是一個好的J2EE產品，對這種有事務關聯的負載均衡，它會優先考慮採用一個服務器裏面的應用，這樣就採用了本地事務，提高了響應速度，減小了分佈式事務對應用和數據庫的壓力。
3、web的優化 我個人認爲，一個商業的應用，硬件的投資可能不是主要的瓶頸，往往可維護性，可擴展性是最主要的問題。
沒有必要採用不成熟的方案，要更多的使用成熟的方案，將靜態、圖片獨立使用不同的服務器，對於常態的靜態文件，採用E-TAG或者客戶端緩存，google很多就是這樣乾的。對於熱點的功能，考慮使用完全裝載到內存，保證絕對的響應速度，對於需要頻繁訪問的熱點數據，採用集中緩存(多個可以採用負載均衡)，減輕數據庫的壓力，比如：很多配置信息，操作員信息等等。
對了，對於幾乎除二進制文件，都應該在L4上配置基於硬件的壓縮方案，減少網絡的流量。提高用戶使用的感知。
4、網絡問題 你不可能要求所有的使用人員，都和你的服務器在一個運營商的網絡內，可以考慮採用鏡像、多路網絡接入、基於DNS的負載均衡。如果有足夠的投資，可以採用CDN(內容分發網)，減輕你的服務器壓力。
二、
F5的負載均衡 是必不可少的，他的每秒點擊量能達到將近30萬，並且它有會話的 粘性，只要是同一個ip發過來的請求，它就會把它分到同一臺機器的，不用 擔心分發錯誤的。現在的問題是apache和tomcat的能力不平衡，動態的內容壓力太大，不是數據庫的壓力，我們的數據庫 oracle是RAC羣集。性能很好
三、
tomcat爲什麼死掉?當時CPU或者內存的佔用率是多少?看看其中JVM佔用了多少?有沒有OOM的錯誤?不可能20臺tomcat只能支撐5000的併發。。。以前做過單臺的resin峯值到3K都是綽綽有餘的。。。把緩存做好，減少動態查詢
四、
1、F5的使用 F5不光可以做web的負載均衡，也可以做基於第4層的負載均衡。 比如：銀行接口，大部分基於socket通訊的，就可以在前面架設一套F5設備，將請求分發到不同的服務器上。
大部分使用F5都是在web層次上，如果使用基於源IP地址的策略，有很多客戶端都是基於代理服務器，這個時候源IP地址是一樣的，其實並沒有把這些用戶給分發到不同的服務器上，建議採用基於cookie insert的方式，採用cookie的會話保持策略，loadbalance的算法，需要仔細的結合自己的應用的實際情況來設置。
2、大併發的問題 現在你得到了一個大概的系統能承受的併發，但是還達不到系統的設計目標。 應該從應用的角度去分析這個問題，web方面，通過工具(httplook)，檢查一下客戶端發起的請求都是什麼響應狀態，如果看到很多304請求狀態，你需要優化你的url緩存，看一下每個url的耗費時間，仔細針對比較慢的進行調優;對於tomcat或者weblogic，在高併發的情況下，用kill -3 ，獲得ThreadDump(HeapDump需要特殊的設置)，看一下在高併發下，jvm的線程到底在幹什麼，仔細的分析可能對你有幫助。
如果在這些還沒有改善的情況下，應當去想一想，硬件是否足夠、配置是否合理等等系統級別的問題。
五、
似乎在說瓶頸在於tomcat併發承載能力不夠，但爲什麼tomcat只能承擔單機200個併發?當併發急劇上升的時候，tomcat在執行動態請求的時候，瓶頸在哪裏?是哪部分程序，或者哪個環節首先導致tomcat失去響應的?在davexin描述的刀片硬件上面，tomcat上面如果跑的僅僅是最簡單的jsp頁面，在採用BEA JRockit JVM的情況下，500個併發也可以達到。
我的推測是瓶頸還是出在EJB遠程方法調用上!
tomcat上面的java應用要通過EJB遠程方法調用，來訪問weblogic上面的無狀態SessionBean，這樣的遠程方法調用一般都在100ms~500ms級別，或者更多。而如果沒有遠程方法調用，即使大量採用spring的動態反射，一次完整的web請求處理在本地JVM內部的完成時間一般也不過20ms而已。一次web請求需要過長的執行時間，就會導致servlet線程被佔用更多的時間，從而無法及時響應更多的後續請求。
如果這個推測是成立的話，那麼我的建議就是既然你沒有用到分佈式事務，那麼就乾脆去掉EJB。weblogic也可以全部撤掉，業務層使用spring取代EJB，不要搞分佈式架構，在每個tomcat實例上面部署一個完整的分層結構。
另外在高併發情況下，apache處理靜態資源也很耗內存和CPU，可以考慮用輕量級web server如lighttpd/litespeed/nginx取代之。
六、
tomcat之所以併發低很可能是由於remote session bean造成的，remote session bean又一次被濫用了，在樓主的這種業務情況下，web層和service層根本不需要分開，象樓主這樣分開帶來就是一訪問業務層就帶來長時間的遠程請求，確實導致tomcat上servlet資源釋放的問題。那麼remote session bean應該被用在什麼地方呢，without ejb上有寫到金融系統常用ejb。我把他的這句話延伸一下，也就是說當業務的運行時間遠超過遠程調用的時間時，我們就可以用remote session bean來把這個業務分離出去。而樓主的系統中沒有這種業務情況。所以使用remote session bean應該來說是一個錯誤的選擇，不過這個錯誤的選擇帶來的危害被大量的硬件所掩蓋，帶來的是成本的提高。而性能上還不如slsb。
所以我覺得如果要改架構最便捷的方法是使用slsb，把remote session bean去掉。這樣改造的成本比較低，如果換成spring+hibernate成本就高得多了。也就是說可以struts+Bean+DAO+helper，然後把weblogic作cluster，任意一個node上都部署相同的應用。也就是水平擴展，理論上來講當性能不滿足要求時添加node就行了，如果能做成農場就更加方便了。當然即使非農場也沒有關係，可以用現在在使用的stick分發。這樣的改造之所以方便是因爲把remote session bean改成slsb是很容易的，而且團隊裏的人估計對ejb都更加熟悉一點，成本會比較低一點
七、
近段時間正在做購買新硬件和新軟件的預算，公司高層準備買weblogic10和oracle 10g，所以請了bea公司的人員和我一塊做測試，經過近幾天的測試，測試一下新的系統指標1萬個併發，需要多少軟件和多少硬件能夠支撐，已經測試了不同的組合方式，有了不同的結果，分別如下：
1。1臺weblogic10 能支持900個用戶併發(沒有用ejb)，平均響應時間 10秒。
2。1臺weblogic10 Express(相當於1臺tomcat，用於發佈jsp應用)加1臺weblogic10(發佈ejb應用)，能支持1000個併發用戶，平均響應時間9秒，由於本人使用的loadRunner最多支持1000個web併發，雖然此時weblogic沒有任何錯誤，但是沒辦法再向上壓用戶，所以不知道最高能支撐多少個併發用戶，很遺憾。
3。1臺weblogic8， 能支持900個用戶併發(沒有用ejb)，平均響應時間 11秒。但是沒有weblogic10在同樣時間內處理的交易數量多。可以判定性能不能weblogic10。
4。1臺tomcat4.1加1臺weblogic8，只能支持350個併發用戶，tomcat就連結超時，說明此種結構瓶頸在tomcat。
5。1臺tomcat6.14加1臺weblogic8，還不如方案4，tomcat結超時更多，說明此種結構瓶頸在tomcat。由於還沒有看tomcat6.14的調優資料。所以還請高手給建議。
6。1臺tomcat4.1加1臺weblogic10，性能同樣不佳，問題出現在tomcat性能跟不上。
7。1臺tomcat6.14加1臺weblogic10，性能同樣不佳，問題出現在tomcat性能跟不上。
明天還要做一個weblogic10 cluster測試，等有了測試結果，再根大家交流。
以上測試機器都爲 linux as4 操作系統，2cpu + 2G內存，發現cpu利用率最高佔45%，一般就在10%左右，內存可以用到1.5G。 loadRunner機器爲2cpu + 2G內存，window server 2003操作系統。
有以上的結果，bea公司人員建議購買16-20cpu的licens。機器購買4cpu + 8G內存機器4-6臺。前端tomcat增加到50臺。
由於根據以前的宕機記錄，主要表現在tomcat層，個別高峯時候也出現在F5。故不敢輕易的捨棄無狀態session bean。由於tomcat做了大部分的業務，只有需要數據庫的時候才調用weblogic中間件，由於weblogic的價格還是比較昂貴的，公司以前購買的weblogic licens數量限制。所以還不能把所有的tomcat換成weblogic。如果有20臺weblogic的licens，我也就不擔心1萬個併發了。
八、
坦白說我還從來沒有聽說過大規模互聯網應用使用EJB的先例。爲什麼大規模互聯網應用不能用EJB，其實就是因爲EJB性能太差，用了EJB幾乎必然出現性能障礙。阿里巴巴和淘寶網那是每天多少億PV的電子商務網站了，其實也就是用JBoss而已，而且也只是用其web容器(JBoss的web容器就是tomcat)，所以本質上還是在用tomcat。
今年年初，RedHat在深圳的HW大客戶在內部做過性能對比評測，JBoss4 vs WebLogic 9，在web容器一項的評測當中，JBoss4勝出。這個結果並不令人感到意外，因爲web容器的性能說到底無非就是Servlet線程調度能力而已，Tomcat不像WebLogic那樣附加n多管理功能，跑得快很正常。這一點你只要對比測試一下WebLogic的數據庫連接池和C3P0連接池的性能也會發現類似的結論，C3P0可要比WebLogic的連接池快好幾倍了。這不是說WebLogic性能不好，只不過weblogic要實現更多的功能，所以在單一的速度方面就會犧牲很多東西。
以我的經驗來判斷，使用tomcat5.5以上的版本，配置apr支持，進行必要的tuning，使用BEA JRockit JVM的話，在你們目前的刀片上面，支撐500個併發完全是可以做到的。結合你們目前20個刀片的硬件，那麼達到1萬併發是沒問題的。當然這樣做的前提是必須扔掉EJB，並置web層和業務層在同一個JVM內部。
從你上面的發言來看，你們之所以採用EJB，無非是因爲經費有限，無法購買充足的weblogic license。所以退而求其次，購買少量的weblogic license，專門跑業務層服務器，用SLSB暴露遠程接口給tomcat調用。然後部署n十多臺免費的tomcat服務器跑web。爲省錢而採用EJB到是一個很新鮮的事，但實際上這就是一個很愚蠢的決定。
weblogic的優秀更多的體現在他對於J2EE標準優秀的支持，各種複雜的企業應用場景以及傳統的中間件應用的豐富而方便的集成手段上。簡單的來說，就是weblogic/websphere是企業應用的首選，特別是強調事務的企業應用，例如金融，電信計費。但在互聯網應用方面，weblogic/websphere根本就體現不出有什麼能夠超過resin/tomcat的地方，誠然weblogic express的web容器穩定性要好於tomcat，但沒有互聯網企業在大規模部署tomcat水平羣集的時候，還會爲這一點而瘋狂買單購買weblogic license。
所以我個人很不理解，作爲一個互聯網公司的CTO，怎麼會如此迷信weblogic，因爲我認識的互聯網公司高層，沒有什麼人願意用商業產品，絕大多數都是用開源的，我不憚揣測他的背景可能來自傳統企業應用出身的吧，呵呵。
九、
這說明瓶頸還不在EJB遠程調用上，但是問題已經逐漸清楚了。爲什麼weblogic充當web容器發起遠程EJB調用的時候可以支撐1000個併發，但是tomcat只能到350個?只有兩個可能的原因：
1、你的tomcat沒有配置好，嚴重影響了性能表現 2、tomcat和weblogic之間的接口出了問題
上面的帖子其實我也介紹過了，如果只是單純的作爲servlet容器來看，tomcat的性能不應該比weblogic差，甚至還要更好，所以你可以這樣來擬定測試方案：
在同樣硬件環境下對比測試tomcat5.5和weblogic10的servlet容器性能，分別寫幾個訪問數據庫，和不訪問數據庫的JSP頁面測試就可以了，併發從500往上走，看看哪個throughput更高。記得要調優tomcat5.5，配置apr支持要打開。
如果測試結果表明tomcat併發響應能力遠遠差於weblogic，那就說明你的tomcat配置有很大的問題，好好鑽研tomcat configuration && performance tuning吧;
如果測試結果表明tomcat併發響應能力與weblogic相當，或者差不多，那麼很不幸，問題不在tomcat本身，而是出在了tomcat到weblogic的接口上。而tomcat是通過weblogic提供的EJB client jar去調用weblogic的EJB的，那你只好諮詢BEA去尋求解決方案了。
十、
1.基礎配置優化 tomcat 6? tomcat參數調優? JRockit JVM? JVM參數調優? Apache+Squid 處理靜態內容?
2.業務層優化 部分功能本地化，而不調remote session bean? 異步提交操作,JMS? cache熱點數據?
3.展示層優化 動態頁面發佈爲靜態頁面? Cache部分動態頁面內容?
十一、
對於樓主的問題，以及公司的架構方案，我認爲你們仍然在犯錯! 誤區：遇到性能問題的第一件事情就是找硬件和容器的事情! 性能問題的基本上無一例外的都出在寫的程序有問題，滿足不了伸縮性。 好好看看你們的程序吧，不要再給bea打電話了，你得到的建議，基本上都是用不到的。 robin的觀點是對的，我甚至懷疑你們的數據庫連接是否有釋放問題的。 增加你們前端的內存，多做緩存。hibernate的cache方案不差jdbc對數據庫的頻繁使用 html的書寫是否符合w3的規範
最好在一個服務器上部署整個應用!
十二、
淘寶用的weblogic8,他們的web層使用的Turbine，且大量的使用velocity，由於對事務要求及其苛刻用到了ejb,也用到spring很多其他服務，訪問數據庫使用ibatis，他們對weblogic優化到的極致加上外面也架了apache,，在如此高併發的情況，且高度複雜的搜索。。。，還能保持如此的響應速度，確實很不錯。
淘寶的搜索功能說是在的非常強大，不曉得是不是yahoo中國來人做的，一直覺得很神奇
robbin大哥說的還是很有道理，對於大多數門戶門戶網站，使用EJB確實浪費，購買weblogic的錢可以購買很多硬件來apache,tomcat負載均衡遠遠勝過於ejb方案的性能。沒有絕對的性能好壞之分，主要還是看你的需求，weblogic永遠是對於銀行，證券，電信的行業所準備，他們所使用的硬件對象也絕對不是刀片，雙路至強的硬件這樣的東東。
十三、
經過今天修改tomcat的參數，修改如下： 經過測試，併發人數是可以達到像robbin所說的一樣，能夠在600人左右，如果壓到併發700人，就有15%左右的失敗，雖然在調整上面參數之後，併發人數上去了，但是在同樣的時間內所完成的事務數量下降了10%左右，並且響應時間延遲了1秒左右，但從整體上來說，犧牲一點事務吞吐量和響應時間，併發人數能夠提高500，覺得還是值得的。謝謝robbin的建議。
由於本人使用的loadRunner 能支持的獨立client數量在100個，所以沒辦法對ejb進行單獨的壓力測試。因爲我在對前段應用調用ejb時，最多併發用戶已經達到1000個，但是通過監控weblogic10中發佈的ejb應用和連接池，發現ejb應用等待數量爲0，但是連接池中最多有60個活動連接，有7個連接在等待，因爲此時設置的weblogic連接池最大數量是60，後來對連接池數量進行增大到160個，再次進行測試，發現性能反而不如把連接池數量調爲60個的時候。問起bea的人，他們也說不清楚原因。
同時對他們所提供的一種更好的jvm進行測試，jvm的名字是 RealTime.發現性能並沒有太大改善。 我們現在的系統已經作了很多的緩存，有全局的，有局部的，都是放到內存中的HashMap，靜態的頁面都是放在apache上的，不過沒有使用 apr， 接下來如果有時間，會測試一下這個咚咚。
che前面是F5負載均衡器，在apache後面是tomcat，tomcat在公網上，然後通過內網網卡訪問weblogic，weblogic才能訪問數據庫，tomcat不能直接訪問數據庫的，由於以前的網絡結構的原因，也有安全的原因，公司還有部分服務器在北京(無線事業部)和廣州(老系統，以後會逐漸遷移到上海)，雖然現在也有其他的安全方案可以把tomcat放在內網，去掉weblogic，但是這種改變是需要時間的，也要考慮平穩過渡，所以還請各位理解。至於購買weblogic，公司也是有自己的考慮的。因爲以前就是運行在weblogic上的，如果現在不用了，如果出了問題，就很難辦了。
十四、
是的，如果調整參數，可以達到併發人數達到1000以上，但是通過對比同樣壓力下的weblogic和tomcat，發現tomcat的響應時間都比weblogic長，並且tomcat的cpu的佔用率達到45%-60%，而同樣的壓力下weblogic的cpu佔用只有3%-5%。內存都是2G都用了97%，說明主要差別表現在cpu和相應時間上，我沒有做tomcat 1000人併發測試，但是從以前600人併發的響應時間判斷，我覺得響應時間可能會超過15秒。所以從綜合各方面性能指標考慮，我覺得要找出一個響應時間，併發人數，完成交易數量3方面考慮折中，找出一個滿足應用響應時間和併發用戶的折中吧，如果是併發交易量比較大的應用，我想應該減少併發用戶，提高單位時間內交易數量來滿足應用需求吧。
十五、
又回到了realtime的定義，並不是很快的意思，而是響應時間是可預計的。
而JVM對響應時間可預計性的影響，主要表現在 1.線程調度受操作系統線程調度的影響 2.垃圾收集引起的暫停
所以jrockit選擇了動態垃圾收集，以頻繁的收集來換取每次中斷時間的減少，所以，對吞吐量來說，是反而會下降的。大部分jvm都有吞吐量優先，短暫停時間兩種截然不同的垃圾收集算法。