所說商業網站便是瀏覽量與總流量都挺大的一些網站，因而新建站前期就需要考慮好當用戶流量做到某一等級是能否支撐點網址再次正常的經營下來。在其中關鍵考慮到的層面有幾個方面：數據庫工作壓力，seo推廣，網絡服務器負荷。

一、

1、數據庫工作壓力難題 每一個工作壓力較終都是會體現到數據庫層面，一定會對數據庫有一個總體的整體規劃。 能夠根據業務流程、地區這些特點對數據庫開展配備，可以選擇儲備庫、使用rac、系統分區、數據透析表這些對策，保證數據庫能正常的的買賣交易。

2、事務管理難題 你采用了這兩種種類數據庫，一個SQL Server、一個oracle，如果一個買賣必須在2個數據庫中實際操作，那樣務必充分考慮分布式事務，你需要細心的設計方案你系統軟件，來防止應用分布式事務，以防止分布式事務產生更多的是數據庫工作壓力和其他難題。推薦你采用延遲時間遞交的對策(并不是保證數據的完整性)，來防止分布式事務的難題，終究commit不成功的可能性比較低。(某一特大型系統軟件，有3套數據庫，都是采用的延遲時間遞交對策，防止分布式事務產生的對數據庫太大的工作壓力)。

看見了你一直在運用前面(weblogic EJB)采用了F5，我本人不太同意這種計劃方案，盡管F5是一個好的L4商品，也可以根據第7層做web服務和容災備份。不過一個有事務管理買賣的EJB，假如采用了這個計劃方案，把不用應用分布式事務的買賣變成了分布式系統買賣，試想，一個web假如在一個請求中，瀏覽了后面2個EJB，那樣L4就會出現很有可能把請求派發到不一樣的服務器上，并沒有對事務管理保持在一個網絡服務器中，就不能使用當地事務管理。一樣，一個web，瀏覽后面一個請求，這一請求中必須3個EJB，那樣很有可能把這3個請求派發到不一樣的網絡服務器，又造成了分布式事務。weblogic是一個好的J2EE商品，對這個有事務管理關系的web服務，它會優先考慮采用一個云服務器里邊的運用，這樣就采用了當地事務管理，提高了響應時間，減少了分布式事務對使用和數據庫的工作壓力。

3、web的提升 我個人認為，一個行業的運用，硬件配置的投入很有可能并不是具體的短板，通常可擴展性，擴展性是較關鍵的難題。

沒有必要采用不成熟的計劃方案，要更多的是應用完善的實施方案，將靜態數據、照片單獨應用差異的網絡服務器，針對常態化的靜態文件，采用E-TAG或是手機客戶端緩存文件，google許多就這樣干的。針對網絡熱點的作用，考慮到應用合理運載到運行內存，確保肯定的響應時間，針對要經常瀏覽的熱門數據信息，采用集中化緩存文件(好幾個能夠采用web服務)，緩解數據庫的工作壓力，例如：許多配置信息，操作工信息內容這些。

正確了，針對基本上除二進制文件，都應該在L4上配備根據硬件配置的縮小計劃方案，降低互聯網的數據流量。增強客戶應用的認知。

4、網絡不穩定 你不可能規定每一個應用工作人員，都和你網絡服務器在一個營運商的互聯網內，可以選擇采用鏡像系統、多通道互聯網接入、根據DNS的web服務。要是有充足的項目投資，能夠采用CDN(具體內容派發網)，緩解你網絡服務器工作壓力。

二、

F5的web服務 是不可缺少的，他們的每秒鐘瀏覽量能做到接近30萬，而且它有對話的 黏性，只需是同一個ip發來的請求，它便會把它分得同一臺設備的，無需 擔憂派發不正確的。現今難題是apache和tomcat的能力不均衡，信息的具體內容壓力大，并不是數據庫的工作壓力，他們的數據庫 oracle是RAC集群。特性非常好

三、

tomcat為什么死掉?那時候CPU或是運行內存的占用量多少錢?看一下在其中JVM占有了是多少?是否有OOM的不正確?不太可能20臺tomcat只有支撐點5000的并發。。。之前做了每臺的resin最高值到3K全是非常合適了的。。。把緩存文件搞好，降低動態查詢

四、

1、F5的應用 F5不僅能夠做web的web服務，也能做根據第4層的web服務。 例如：銀行接口，絕大多數根據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年的網站建設工作經驗，更需要立在客戶的視角去網站設計，合乎大部分人應用習慣性，做更加好的客戶體驗！