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

一、

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。北京網站建設創新互聯有的不僅僅是8年的網站建設經驗，更多的是站在用戶的角度去設計網站，符合大多數人的使用習慣，做更好的用戶體驗！

網站名稱：建設大型網站要考慮數據庫壓力和服務器負載
網站路徑：http://m.js-pz168.com/news6/108356.html

成都網站建設公司_創新互聯，為您提供用戶體驗、微信公眾號、網站建設、自適應網站、定制網站、全網營銷推廣

廣告

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