大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案

大規(guī)模網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案目錄11的性能瓶頸分析2系統(tǒng)架構(gòu)設(shè)計32.1總體思路3負(fù)載平衡32.1.2WEB應(yīng)用開發(fā)架構(gòu)的WEB思想32.1.3數(shù)據(jù)存儲的設(shè)計思路2.1.4不同網(wǎng)絡(luò)用戶的訪問注意事項42.2總體架構(gòu)52.2.1系統(tǒng)層次結(jié)構(gòu)52.2.2物理架構(gòu)62.2.3發(fā)展框架網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)82.3架構(gòu)相關(guān)技術(shù)的詳細(xì)說明9負(fù)載平衡9高速緩存152.3.3頁面靜態(tài)19數(shù)據(jù)庫配置和優(yōu)化20文件存儲212.3.6網(wǎng)絡(luò)問題的解決方案242.3.7WEB應(yīng)用開發(fā)架構(gòu)的WEB設(shè)計思想262.4系統(tǒng)軟件參數(shù)優(yōu)化30操作系統(tǒng)優(yōu)化302.4.2tomcat服務(wù)器優(yōu)化312.4.3pache服務(wù)器優(yōu)化332.4.4nginx服務(wù)器的優(yōu)化333Web服務(wù)架構(gòu)評估343.1測試環(huán)境34網(wǎng)絡(luò)環(huán)境34服務(wù)器配置35軟件環(huán)境353.2測試結(jié)果403.2.1單個TOMCAT40的WEB服務(wù)器3.2.2Nginx+2TOMCATWEB服務(wù)器413.2.3ginx+2個TOMCATWEB服務(wù)器+緩沖區(qū)423.3測試結(jié)果分析433.4評估結(jié)果444配置選擇454.1網(wǎng)絡(luò)帶寬454.2架構(gòu)和硬件配置選擇46硬件配置參考464.2.2Web架構(gòu)和硬件選擇474.3硬件容量擴(kuò)展策略484.3.1添加服務(wù)器484.3.2增加存儲48升級服務(wù)器48網(wǎng)絡(luò)擴(kuò)展48附錄5:部分主流真實(shí)數(shù)據(jù)49性能瓶頸分析基于影響性能的因素很多，主要從以下四個方面進(jìn)行分析和說明:電網(wǎng)負(fù)荷公共網(wǎng)絡(luò)負(fù)載凈負(fù)荷WEB應(yīng)用服務(wù)器性能中央處理器內(nèi)存、輸入/輸出訪問商店并發(fā)TCP/IP連接數(shù)服務(wù)器性能數(shù)據(jù)庫參數(shù)配置服務(wù)器性能(CPU、內(nèi)存、存儲)數(shù)據(jù)結(jié)構(gòu)的合理性不同的WEB應(yīng)用處理方法有不同的性能瓶頸。對于靜態(tài):靜態(tài)HTML頁面由標(biāo)準(zhǔn)的HTML標(biāo)記語言嚴(yán)格組成，不需要在服務(wù)器端實(shí)時操作生成。這意味著在對一個靜態(tài)HTML文檔發(fā)出訪問請求后，服務(wù)器只需將文檔傳輸給客戶機(jī)。從服務(wù)器運(yùn)行時的時間片來看，這個傳輸過程只占用少量的CPU資源。靜態(tài)HTML的訪問瓶頸是:網(wǎng)絡(luò)帶寬、磁盤I/O和緩存。對于動態(tài)頁面因為服務(wù)器在將動態(tài)頁面?zhèn)鬏數(shù)娇蛻舳酥氨仨殞ζ溥M(jìn)行解釋，所以會給應(yīng)用服務(wù)器增加額外的性能消耗，如果要進(jìn)一步訪問數(shù)據(jù)庫，會增加數(shù)據(jù)庫服務(wù)器的性能消耗，所以動態(tài)頁面還有額外的瓶頸:應(yīng)用服務(wù)器的性能和數(shù)據(jù)庫服務(wù)器的性能。系統(tǒng)架構(gòu)設(shè)計大意為了提高高并發(fā)性能、開發(fā)效率和運(yùn)行效率，主要按照以下思路進(jìn)行規(guī)劃和設(shè)計:負(fù)載均衡四層交換負(fù)載平衡:負(fù)載均衡器用于實(shí)現(xiàn)硬件級的四層交換負(fù)載均衡，或者LVS用于實(shí)現(xiàn)軟件的四層交換負(fù)載均衡。使用第三方軟件實(shí)現(xiàn)負(fù)載均衡和緩存頁面請求。反向代理服務(wù)器集群由Nginx實(shí)現(xiàn)，squid集群設(shè)置為靜態(tài)頁面和圖片的緩存。負(fù)載均衡是通過web服務(wù)器的配置來實(shí)現(xiàn)的。即客戶的請求通過apache或Nginx平均分配給Tomcat1和Tomcat2進(jìn)行處理。對WEB應(yīng)用開發(fā)架構(gòu)的思考應(yīng)用開發(fā)，MVC架構(gòu)，三層架構(gòu)，web應(yīng)用開發(fā)頁面盡可能靜態(tài)，以減少動態(tài)數(shù)據(jù)訪問。如果是信息類型，可以考慮第三方開源CMS系統(tǒng)生成靜態(tài)內(nèi)容頁面。Oscache用于實(shí)現(xiàn)頁面緩存，Memcached用于實(shí)現(xiàn)數(shù)據(jù)緩存。采用獨(dú)立的圖像服務(wù)器集群實(shí)現(xiàn)圖像資源存儲和WEB請求。數(shù)據(jù)存儲的設(shè)計思想數(shù)據(jù)庫拆分，將生產(chǎn)數(shù)據(jù)庫與查詢數(shù)據(jù)庫分開，并使用RAC對生產(chǎn)數(shù)據(jù)庫進(jìn)行集群化。采用高效的網(wǎng)絡(luò)文件共享策略，并采用圖像服務(wù)器實(shí)現(xiàn)頁面的圖像存儲。不同的網(wǎng)絡(luò)用戶訪問注意事項通過引入CDN來解決不同網(wǎng)絡(luò)服務(wù)商的訪問速度問題，只能解決靜態(tài)頁面的訪問問題。在不同運(yùn)營商機(jī)房部署服務(wù)器，通過鏡像技術(shù)實(shí)現(xiàn)不同網(wǎng)絡(luò)服務(wù)商的訪問速度。整體架構(gòu)系統(tǒng)分層架構(gòu)基于的物理架構(gòu)的開發(fā)框架網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)備注:采用雙防火墻和雙交換機(jī)進(jìn)行網(wǎng)絡(luò)冗余，保證平臺服務(wù)。雙防火墻用于通知雙線互聯(lián)網(wǎng)接入的連接，設(shè)備之間使用VRRP協(xié)議。在任何防火墻或互聯(lián)網(wǎng)出現(xiàn)故障后，流量可以自動切換到另一端以確保的正常運(yùn)行，并且設(shè)備或網(wǎng)絡(luò)將自動恢復(fù)。雙千兆交換機(jī)分別連接到兩個防火墻。當(dāng)某個設(shè)備或網(wǎng)絡(luò)鏈路出現(xiàn)故障時，好的設(shè)備會自動接管壞設(shè)備的工作，不會影響整體運(yùn)行。根據(jù)業(yè)務(wù)和真實(shí)服務(wù)器的數(shù)量，可以隨時增加交換機(jī)。硬件負(fù)載均衡器用于實(shí)現(xiàn)網(wǎng)絡(luò)流量的負(fù)載均衡。使用硬件負(fù)載均衡器將網(wǎng)絡(luò)流量平均分配給WEB服務(wù)器集群中的各個節(jié)點(diǎn)服務(wù)器，從而保證平臺服務(wù)器資源的均衡使用。采用代理服務(wù)器實(shí)現(xiàn)軟件級的網(wǎng)絡(luò)負(fù)載均衡。服務(wù)器分為生產(chǎn)數(shù)據(jù)庫集群和查詢數(shù)據(jù)庫集群，實(shí)現(xiàn)了生產(chǎn)讀寫與后臺查詢統(tǒng)計的分離。同時，生產(chǎn)數(shù)據(jù)庫采用rac技術(shù)。架構(gòu)和技術(shù)的詳細(xì)說明負(fù)載均衡基于DNS的負(fù)載平衡-一個附加域有多個IPDNS負(fù)載均衡技術(shù)是最早的負(fù)載均衡解決方案，是通過DNS服務(wù)中的隨機(jī)名稱解析來實(shí)現(xiàn)的。在DNS服務(wù)器中，同一個名字可以配置很多不同的地址，最終查詢到這個名字的客戶端在解析這個名字的時候會得到其中一個地址。因此，對于同一個名稱，不同的客戶端會得到不同的地址，它們會訪問不同地址的Web服務(wù)器，從而達(dá)到負(fù)載均衡的目的。該技術(shù)實(shí)現(xiàn)簡單，易于實(shí)現(xiàn)，成本低，適用于大多數(shù)TCP/IP應(yīng)用。但是，它的缺點(diǎn)也非常明顯。首先，這個方案不是真正意義上的負(fù)載平衡。DNS服務(wù)器將請求平均分配給后臺Web服務(wù)器，而不管每個Web服務(wù)器的當(dāng)前負(fù)載。如果后臺Web服務(wù)器的配置和處理能力不一樣，最慢的Web服務(wù)器就會成為系統(tǒng)的瓶頸，處理能力強(qiáng)的服務(wù)器就發(fā)揮不了作用；其次，沒有考慮容錯。如果后臺的Web服務(wù)器出現(xiàn)故障，DNS服務(wù)器仍會將DNS請求分配給該故障服務(wù)器，從而導(dǎo)致無法響應(yīng)客戶端。最后一點(diǎn)是致命的，可能會導(dǎo)致相當(dāng)一部分客戶無法享受Web服務(wù)，并且由于DNS緩存(一般DNS刷新周期在24小時左右)造成的后果會持續(xù)很長時間。因此，這種方案在最新的國外建設(shè)中心網(wǎng)站方案中很少使用。通過硬件四層交換實(shí)現(xiàn)負(fù)載均衡。在硬件四層交換產(chǎn)品領(lǐng)域，有一些知名的產(chǎn)品可供選擇，如Alteon、F5等。這些產(chǎn)品非常昂貴，但它們物有所值，可以提供出色的性能和靈活的管理能力。雅虎在中國的近2000臺服務(wù)器使用了三到四臺Alteon的服務(wù)器。通過軟件四層交換實(shí)現(xiàn)負(fù)載均衡。我們可以用Linux上常用的LVS來解決軟件四層交換。LVS是Linux虛擬服務(wù)器。它提供了基于心跳的實(shí)時災(zāi)難響應(yīng)解決方案，提高了系統(tǒng)的健壯性，同時提供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應(yīng)用需求，這對于分布式系統(tǒng)來說是必不可少的。使用負(fù)載均衡的典型策略是在軟件或硬件的四層交換的基礎(chǔ)上構(gòu)建squid集群。很多大型搜索引擎，包括搜索引擎，都采用這種思路。該架構(gòu)成本低、性能高、可擴(kuò)展性強(qiáng)。通過反向代理服務(wù)器實(shí)現(xiàn)負(fù)載平衡反向代理服務(wù)器，也稱為WEB加速服務(wù)器，位于WEB服務(wù)器的前端，充當(dāng)WEB服務(wù)器的緩存。WEB服務(wù)器設(shè)置反向代理服務(wù)器，后臺WEB服務(wù)器對互聯(lián)網(wǎng)用戶透明。用戶只能看到反向代理服務(wù)器的地址，不清楚后臺WEB服務(wù)器是如何組織的。當(dāng)互聯(lián)網(wǎng)用戶請求WEB服務(wù)時，DNS將請求的域名解析為反向代理服務(wù)器的IP地址，這樣URL請求就會被發(fā)送到反向代理服務(wù)器，反向代理服務(wù)器將負(fù)責(zé)處理用戶的請求和響應(yīng)，并與后臺WEB服務(wù)器進(jìn)行交互。反向代理服務(wù)器減輕了后臺WEB服務(wù)器的負(fù)載，提高了訪問速度，避免了用戶與WEB服務(wù)器直接通信帶來的安全隱患。目前反向代理軟件很多，其中Nginx和Squid比較有名。Nginx是伊戈爾·塞索耶夫為俄羅斯訪問量第二大的網(wǎng)站Rambler.ru開發(fā)的。它是一個高性能的反向代理服務(wù)器，也是一個IMAP/POP3/SMTP代理服務(wù)器。Squid是美國政府資助的一個研究項目。其目的是解決網(wǎng)絡(luò)帶寬不足的問題，支持S、FTP等多種協(xié)議。它是目前Unix系統(tǒng)上使用的功能最多、最完整的一套軟件。魷魚Squid是一款開源軟件，其反向代理技術(shù)可以提高系統(tǒng)的訪問速度。下面將重點(diǎn)介紹Squid反向代理的實(shí)現(xiàn)原理及其在提高性能方面的應(yīng)用。Squid反向代理服務(wù)器位于本地WEB服務(wù)器和Internet之間，其組織結(jié)構(gòu)如下:當(dāng)客戶端請求訪問WEB服務(wù)時，DNS將訪問的域名解析為Squid反向代理服務(wù)器的IP地址，這樣客戶端的URL請求就會被發(fā)送到反向代理服務(wù)器。如果請求的資源緩存在Squid反向代理服務(wù)器中，則請求的資源會直接返回給客戶端；否則，反向代理服務(wù)器將從后臺WEB服務(wù)器請求資源，然后將請求的響應(yīng)返回給客戶端，并將響應(yīng)緩存在本地以供下一個請求者使用。Squid反向代理一般只緩存可以緩存的數(shù)據(jù)(如html網(wǎng)頁、圖片)，而一些CGI腳本程序或ASP、JSP等動態(tài)程序默認(rèn)不緩存。它根據(jù)從WEB服務(wù)器返回的header標(biāo)記緩沖靜態(tài)頁面。有四個最重要的標(biāo)題標(biāo)簽:Last-Modified:告訴反向代理頁面何時被修改。Expires:告訴反向代理頁面何時應(yīng)該從緩沖區(qū)中刪除它。Cache-Control:告訴反向代理頁面是否應(yīng)該被緩沖。Pragma:用于包含特定于實(shí)現(xiàn)的指令，最常用的是Pragma:no-cache。注意:DNS的輪詢機(jī)制將一個域名解析為多個IP地址。NginxNginx(“引擎x”)是一個高性能的反向代理服務(wù)器，由俄羅斯伊戈爾塞索耶夫(塞索耶夫)編寫。Nginx已經(jīng)在俄羅斯最大的門戶網(wǎng)站漫步者媒體上運(yùn)行了4年，俄羅斯超過20%的虛擬主機(jī)平臺使用Nginx作為反向代理服務(wù)器。在中國，有新浪博客、新浪播客、搜狐通行證、網(wǎng)易新聞、網(wǎng)易博客、金山X、金山詞霸、校內(nèi)網(wǎng)、YUPOO相冊、豆瓣、迅雷侃侃等，很多頻道都使用Nginx服務(wù)器。Nginx的特點(diǎn)如下:工作在OSI模型的第7層(應(yīng)用層)高并發(fā)連接官方測試可以支持50000個并發(fā)連接，在實(shí)際生產(chǎn)環(huán)境下可以達(dá)到20000~30000個并發(fā)連接。少存錢在30000個并發(fā)連接下，10個openNginx進(jìn)程只消耗150M內(nèi)存(15M*10=150M)。配置文件非常簡單風(fēng)格和程序一樣容易理解。低成本Nginx是開源軟件，可以免費(fèi)使用。而購買F5BIG-IP、NetScaler等硬件負(fù)載均衡交換機(jī)則需要十幾萬到幾十萬人民幣。支持重寫重寫規(guī)則?？梢愿鶕?jù)不同的域名和URL將請求分成不同的后端服務(wù)器組。設(shè)置健康檢查功能如果Nginx代理后端的一個Web服務(wù)器宕機(jī)，不會影響前端訪問。節(jié)省帶寬支持GZIP壓縮，可以添加瀏覽器本地緩存頭。高穩(wěn)定性對于反向代理，宕機(jī)的概率很小。Nginx+squid頁面緩存實(shí)現(xiàn)反向代理負(fù)載均衡通過Nginx反向代理和squid緩存實(shí)現(xiàn)動靜分離的架構(gòu)圖如下:Apache+tomcat集群實(shí)現(xiàn)負(fù)載均衡。用apache和多個tomcat配置一個適用的web，用Apache分發(fā)請求，用tomcat1，tomcat2等根據(jù)權(quán)重處理請求。的電流負(fù)載，以滿足以下要求:Apache作為服務(wù)器，通過mod_jk連接器連接多個tomcat應(yīng)用實(shí)例，進(jìn)行負(fù)載均衡。同時要配置會話復(fù)制，也就是說任何一個tomcat增加的會話都要同步復(fù)制到其他Tomcat上。集群中的Tomcat都有相同的會話，應(yīng)該為系統(tǒng)(包括Apache和Tomcat)設(shè)置會話超時時間。躲藏系統(tǒng)架構(gòu)的緩存魷魚緩存 Squid緩存了模式。注意:SQUID使用LM算法，LM是頁眉中的時間(日期)和上次修改時間之間的差值。Date通常是Squid從后面取頁面的時間，Last-Modified通常是頁面生成時間。Nginx的緩存功能從0.7.48版本開始，Nginx支持類似Squid的緩存。以緩存URL和相關(guān)組合為密鑰，用md5哈希后保存；Nginx的Web緩存服務(wù)只能為指定的URL或狀態(tài)碼設(shè)置過期時間，不支持類似Squid的PURGE指令手動清除指定的緩存頁面；對于MMAP實(shí)現(xiàn)，設(shè)置的緩沖區(qū)大小不能超過物理內(nèi)存+SWEB的值?；贛emcached的緩存Nginx支持memcached，但是功能不是特別強(qiáng)，性能還是很優(yōu)秀的。位置/內(nèi)存/{如果($uri~“^/mem/([0-9a-za-z_]*)$”){設(shè)置$memcached_key"$1memcached_pass:11211；}過期70；}此配置將指向sudone。/mem/abc到memcachedabc的鍵來獲取數(shù)據(jù)。目前INX還沒有任何寫memcached的機(jī)制，所以把數(shù)據(jù)寫到memcached里還得靠后臺的動態(tài)語言來完成，你可以用404定向到后端寫數(shù)據(jù)。Nginx的傳統(tǒng)緩存的缺點(diǎn)是不同于squid等其他緩存軟件的，所以也算是它的優(yōu)點(diǎn)吧。在生產(chǎn)應(yīng)用中，它經(jīng)常與squid一起使用。魷魚適合做膠帶？往往不能被阻止，但nginx可以阻止其訪問，例如:sudone。/?還有sudone。/在魷魚上會被當(dāng)作兩個，所以會造成兩個貫穿；Nginx不管變成sudone都只會保存一次。/?1或sudone。/?23、不能通過nginx緩存，從而有效保護(hù)后端主機(jī)。Nginx會誠實(shí)地將表單保存到文件系統(tǒng)中，這樣一來，它可以很容易地在緩存機(jī)器上檢查自己的緩存狀態(tài)和容量，還可以方便地與rsync等其他文件管理器一起使用。它完全是一個文件系統(tǒng)結(jié)構(gòu)。應(yīng)用程序端緩存OSCacheOSCache由OpenSymphony設(shè)計，是一款開創(chuàng)性的JSP定制標(biāo)記應(yīng)用，在現(xiàn)有JSP頁面中提供快速緩存和緩沖的功能。OSCache是一個廣泛使用的高性能J2EE緩存框架，OSCache可以作為任何Java應(yīng)用程序的通用緩存解決方案。OSCache有以下特點(diǎn):緩存任意對象，可以無限制的緩存一些jsp頁面或者請求，任意java對象都可以緩存。OSCacheAPI給你一個全面的程序來控制OSCache的所有特性。永久緩存——緩存可以隨意寫入硬盤，因此它允許創(chuàng)建昂貴的數(shù)據(jù)保留緩存，甚至重新啟動應(yīng)用程序。支持集群——集群緩存數(shù)據(jù)可以單獨(dú)配置，無需修改代碼。記錄的過期——可以最大程度地控制緩存對象的過期，包括可插拔刷新策略(如果默認(rèn)性能不需要的話)。OSCache是應(yīng)用最廣泛的緩存方案，oss、Hibernate、Spring等都支持。OSCache的特點(diǎn):1)緩存任意對象:可以無限制的緩存一些jsp頁面或者請求，任意java對象都可以緩存。2)擁有一個全面的API:OSCacheAPI允許你以編程方式控制所有OSCache特性。3)永久緩存:緩存可以配置為寫入硬盤，從而允許緩存在應(yīng)用服務(wù)器的多個生命周期中創(chuàng)建昂貴的數(shù)據(jù)。4)集群支持:集群緩存數(shù)據(jù)可以單獨(dú)配置，無需修改代碼。5)緩存過期:可以最大程度控制緩存對象的過期，包括可插拔刷新策略(如果默認(rèn)性能不能滿足需要)。MemcachedMemcached是一個高性能的分布式緩存服務(wù)器。一般目的是通過緩存數(shù)據(jù)庫查詢結(jié)果來減少數(shù)據(jù)庫訪問次數(shù)，從而提高動態(tài)Web應(yīng)用的速度和可擴(kuò)展性。Memcached是鍵/值形式的單對象緩存。自行開發(fā)的數(shù)據(jù)存儲和緩存服務(wù)獨(dú)立進(jìn)程緩存服務(wù)對于一些常用的動態(tài)數(shù)據(jù)，通過開發(fā)者服務(wù)緩存在內(nèi)存中，提供給其他子系統(tǒng)調(diào)用。例如，可以用這種方式緩存以下數(shù)據(jù)。用戶基本信息和狀態(tài)的信息緩沖列表緩存，類似于論壇中的帖子列表。記錄帖子數(shù)量的緩存，例如論壇版塊中有多少帖子，以便于分頁。復(fù)雜的分組、求和及計數(shù)查詢，如點(diǎn)數(shù)的分類和排名。集成在WEB應(yīng)用程序中的內(nèi)存緩存在web應(yīng)用程序中，滿負(fù)荷存儲被認(rèn)為是為了確保絕對響應(yīng)速度。對于需要頻繁訪問的熱點(diǎn)數(shù)據(jù)，采用集中緩存(負(fù)載均衡可以用于很多)來減輕數(shù)據(jù)庫的壓力，比如大量的配置信息，操作員信息等等。頁碼靜態(tài)HTML頁面由標(biāo)準(zhǔn)的HTML標(biāo)記語言嚴(yán)格組成，不需要在服務(wù)器端實(shí)時操作生成。這意味著在對一個靜態(tài)HTML文檔發(fā)出訪問請求后，服務(wù)器只需將文檔傳輸給客戶機(jī)。從服務(wù)器運(yùn)行時的時間片來看，這個傳輸過程只占用少量的CPU資源。分頁就是用效率最高、消耗最低的純靜態(tài)html頁面代替動態(tài)頁面。我們盡量使用靜態(tài)頁面來實(shí)現(xiàn)我們的網(wǎng)頁。這個最簡單的方法其實(shí)是最有效的。同時采用第三方開源CMS系統(tǒng)實(shí)現(xiàn)內(nèi)容的管理。對于大量頻繁更新的頁面，我們無法手動逐個實(shí)現(xiàn)靜態(tài)頁面，因此需要引入通用信息發(fā)布系統(tǒng)(CMS)，通過最簡單的信息輸入，自動生成靜態(tài)頁面。對于一個大的規(guī)模，有一個有效的和可管理的CMS是必不可少的。同時，HTML靜態(tài)也是一些緩存策略使用的手段。對于經(jīng)常使用數(shù)據(jù)庫查詢但更新能力不大的應(yīng)用，可以考慮使用HTML靜態(tài)，比如論壇中論壇的公共設(shè)置信息。這些信息目前主流論壇都可以后臺管理，存儲在數(shù)據(jù)庫中。其實(shí)這些信息有大量是被前臺程序調(diào)用的，但是更新頻率很小，所以我們可以考慮在后臺更新的時候把這部分做成靜態(tài)的，這樣就避免了大量的數(shù)據(jù)庫訪問請求。在使html靜態(tài)化時，還可以采用一種折中的方法，即前端繼續(xù)使用動態(tài)實(shí)現(xiàn)，在一定的策略下，后端模塊定時從動態(tài)網(wǎng)頁生成靜態(tài)頁面，定時判斷調(diào)用，可以實(shí)現(xiàn)很多靈活的操作。為了提高靜態(tài)HTML的訪問效率，可以從以下幾個方面進(jìn)行優(yōu)化:網(wǎng)絡(luò)帶寬、磁盤I/O和緩存。數(shù)據(jù)庫配置和優(yōu)化數(shù)據(jù)庫集群 RAC用于生產(chǎn)數(shù)據(jù)庫的集群化。數(shù)據(jù)庫和表的散列將生產(chǎn)數(shù)據(jù)庫和查詢數(shù)據(jù)庫分開，根據(jù)系統(tǒng)業(yè)務(wù)數(shù)據(jù)的特點(diǎn)拆分大表，對訪問較多的表使用分區(qū)表。使用讀/寫數(shù)據(jù)庫分離，隨著系統(tǒng)變得越來越大，尤其是當(dāng)它們的SQL性能很差時，數(shù)據(jù)庫服務(wù)器通常不足以處理負(fù)載。但是多個數(shù)據(jù)庫意味著重復(fù)，除非你把數(shù)據(jù)分開。更一般地說，這意味著建立一個主/從副本系統(tǒng)，在這個系統(tǒng)中，程序?qū)阉械母?、插入和刪除更改語句寫入主庫，所有的選擇數(shù)據(jù)將從從數(shù)據(jù)庫(或多個從數(shù)據(jù)庫)中讀取。雖然概念簡單，但是要合理準(zhǔn)確的實(shí)現(xiàn)并不容易，可能需要大量的代碼工作。所以，即使一開始使用同一個數(shù)據(jù)庫服務(wù)器，也要盡早計劃使用單獨(dú)的DB連接進(jìn)行PHP的讀寫。如果這項工作做對了，系統(tǒng)可以擴(kuò)展到2臺、3臺甚至12臺服務(wù)器，具有高可用性和穩(wěn)定性。擁有良好的數(shù)據(jù)庫配置和備份很多公司沒有很好的備份機(jī)制，也不知道如何正確的做到這一點(diǎn)。光靠Imp是不夠的，還需要熱備份，才能獲得超快的速度和高可靠性。此外，所有備份文件在從服務(wù)器傳輸之前都應(yīng)進(jìn)行壓縮和加密。此外，確保您有關(guān)于安全性、性能和穩(wěn)定性的設(shè)計良好且有用的設(shè)置，包括防止數(shù)據(jù)損壞，其中許多設(shè)置非常重要。文件存儲器文件共享HDFS(政府統(tǒng)計處)HDFS是ApacheHadoop項目中的一個分布式文件系統(tǒng)實(shí)現(xiàn)，基于Google在2003年10月發(fā)表的Google文件系統(tǒng)(GFS)論文。特點(diǎn)硬件要求低高容錯性易于擴(kuò)展簡單配置超大文件HDFS采用主/從架構(gòu)。 HDFS集群由一個Namenode和一定數(shù)量的Datanodes組成。請比較NFSGFS首先，分析它們的功能。NFS網(wǎng)絡(luò)文件系統(tǒng)是由SUN公司開發(fā)的。它是FreeBSD支持的文件系統(tǒng)之一，允許系統(tǒng)與網(wǎng)絡(luò)上的其他系統(tǒng)共享目錄和文件。使用NFS，用戶和程序可以像訪問本地文件一樣訪問遠(yuǎn)程系統(tǒng)上的文件。GFS是Google為滿足公司快速增長的數(shù)據(jù)處理需求而開發(fā)的文件系統(tǒng)。GFS是一個可擴(kuò)展的分布式文件系統(tǒng)，用于訪問大量數(shù)據(jù)的大規(guī)模分布式應(yīng)用程序。它是為谷歌的計算機(jī)集群設(shè)計的，并專門為谷歌的頁面搜索的存儲進(jìn)行了優(yōu)化。所以從功能上來說，它們是完全不同的概念。其次，從結(jié)構(gòu)上比較，NFS至少包括兩個主要部分:一個服務(wù)器與至少一個客戶端通信。共享目錄和文件存儲在服務(wù)器上，客戶端遠(yuǎn)程訪問存儲在服務(wù)器上的數(shù)據(jù)。GFS由一個主服務(wù)器(通常有幾個備份)和幾個中繼服務(wù)器組成。GFS中的文件被備份到固定大小的trunk中，這些trunk存儲在不同的Trunk服務(wù)器上，并且每個Trunk有多個副本(例如，3個副本)，這些副本也存儲在不同的Trunk服務(wù)器上。Master負(fù)責(zé)維護(hù)GFS中的元數(shù)據(jù)，即文件名和主干信息?？蛻舳耸紫葟闹鞣?wù)器獲取文件的元數(shù)據(jù)，然后根據(jù)要讀取的數(shù)據(jù)在文件中的位置與對應(yīng)的TrunkServer進(jìn)行通信，獲取文件數(shù)據(jù)。從跨平臺的角度來看，NFS的基本原理是“允許不同的客戶端和服務(wù)器通過一組RPC共享同一個文件系統(tǒng)”。它獨(dú)立于操作系統(tǒng)，允許不同的操作系統(tǒng)共享文件。而GFS則沒有這個功能。文件只能由集群系統(tǒng)中的PC訪問，這些PC的操作系統(tǒng)一般是Linux。最后，與規(guī)模相比，HDFS只適用于海量數(shù)據(jù)共享。目前，谷歌擁有超過200個GFS集群，其中一些集群擁有超過5000臺PC。集群的數(shù)據(jù)存儲規(guī)?？蛇_(dá)5PB，集群內(nèi)數(shù)據(jù)讀寫吞吐量可達(dá)每秒40G。而NFS一般沒有這么大的規(guī)模?；诘亩喾?wù)器文件自動同步 使用Linux2.6內(nèi)核的inotify來監(jiān)控Linux文件系統(tǒng)事件。 使用開源的lsync監(jiān)控一個目錄，如果目錄文件被添加、刪除或更改，使用Rsync協(xié)議自動同步到多臺服務(wù)器。圖像服務(wù)器分離 特別是，如果程序和圖片放在同一個APAHCE服務(wù)器下，對每個圖片的請求都可能導(dǎo)致對一個D進(jìn)程的調(diào)用。使用獨(dú)立的圖片服務(wù)器不僅可以避免上述情況，還可以對不同使用屬性的圖片設(shè)置不同的過期時間，使得同一用戶在不同頁面訪問同一張圖片時不會再次從服務(wù)器(基于緩存服務(wù)器)取數(shù)據(jù)，不僅速度快，而且節(jié)省帶寬。也就是說，緩存時間也可以獨(dú)立調(diào)整。網(wǎng)絡(luò)問題的解決方案你不能要求所有用戶都和你的服務(wù)器在同一個運(yùn)營商的網(wǎng)絡(luò)，不同網(wǎng)絡(luò)之間的訪問速度會很慢。我們可以通過鏡像和引入CDN來解決這個問題。智能DNS解析我們可以在不同的網(wǎng)絡(luò)運(yùn)營商部署web服務(wù)器，通過linux上的rsync工具自動同步到不同網(wǎng)絡(luò)接入商的web服務(wù)器上，作為主站的鏡像。然后，智能DNS解析被配置為將不同網(wǎng)絡(luò)的訪問用戶引導(dǎo)到相應(yīng)網(wǎng)絡(luò)運(yùn)營商的web服務(wù)器。加拿大如果有足夠的投入，還可以使用CDN(內(nèi)容分發(fā)網(wǎng)絡(luò))將靜態(tài)內(nèi)容(靜態(tài)頁面和圖片)緩存在CDN中，減輕服務(wù)器的壓力。CDN的全稱是ContentDeliveryNetwork，即內(nèi)容交付網(wǎng)絡(luò)。它采用分布式網(wǎng)絡(luò)緩存結(jié)構(gòu)(即國際上流行的webcache技術(shù))，其目的是通過在現(xiàn)有互聯(lián)網(wǎng)上增加新的網(wǎng)絡(luò)結(jié)構(gòu)，將內(nèi)容發(fā)布到離用戶最近的網(wǎng)絡(luò)“邊緣”，讓用戶就近獲取所需內(nèi)容，解決互聯(lián)網(wǎng)網(wǎng)絡(luò)的擁塞，提高用戶訪問的響應(yīng)速度。技術(shù)上，網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點(diǎn)分布不均等造成的用戶訪問響應(yīng)速度慢的問題。得到了全面解決。(即把一臺服務(wù)器的容量平均分成多臺服務(wù)器，智能識別服務(wù)器，讓用戶得到離自己最近的服務(wù)器，速度提高。目前中國訪問量較高的大型公司，如新浪、網(wǎng)易等，都采用了CDN網(wǎng)絡(luò)加速技術(shù)。雖然他們的訪問量很大，但無論他們訪問哪里，都會感覺很快。一般如果服務(wù)器在中國網(wǎng)通，電信用戶訪問慢，如果服務(wù)器在中國電信，網(wǎng)通用戶訪問慢。WEB應(yīng)用開發(fā)架構(gòu)的設(shè)計思想基于MVC的三層應(yīng)用開發(fā)架構(gòu)web應(yīng)用開發(fā)MVC三層架構(gòu)的應(yīng)用與實(shí)現(xiàn)，使用ibatis作為持久層框架，使用c3p0作為數(shù)據(jù)庫連接池。IBATIS是一個框架，可以為Java應(yīng)用程序設(shè)計和實(shí)現(xiàn)更好的持久層。TIS使用XML描述符將對象與存儲過程或SQL語句相關(guān)聯(lián)。簡單是iBATIS最大的優(yōu)點(diǎn)。Ibatis——使用ibatis的十大理由1.能夠操作至少10種數(shù)據(jù)庫。2.可配置緩存(包括從屬緩存)支持?jǐn)?shù)據(jù)源、本地事務(wù)管理和全局事務(wù)的簡單XML配置文檔。5.支持映射、集合、列表和簡單類型包裝(如Integer、String)、JavaBeans類(get/set方法)和復(fù)雜對象映射(如填充列表、復(fù)雜對象模型)。對象模型從來不是完美的(不需要修改)，數(shù)據(jù)模型也從來不是完美的(不需要修改)。你已經(jīng)會SQL了，為什么還要學(xué)別的？.6.4.3.MVC架構(gòu)示意圖Struts架構(gòu)客戶端發(fā)送請求，最后通過Struts框架得到響應(yīng)。這個過程非常重要，是理解Struts框架的關(guān)鍵。上圖描述了Struts框架的結(jié)構(gòu)，下圖通過一個活動圖更具體地描述了從接受請求到返回響應(yīng)的整個過程:面向服務(wù)的應(yīng)用架構(gòu)面向服務(wù)的應(yīng)用程序架構(gòu)是指構(gòu)建一個分布式和非集中式的服務(wù)器平臺，以提供許多不同的應(yīng)用程序。數(shù)據(jù)庫被分成很多小的部分，圍繞每個部分會創(chuàng)建一個服務(wù)接口(API)，而這個接口是訪問數(shù)據(jù)庫的唯一途徑。最終，數(shù)據(jù)庫演變成一個巨大的共享資源。這種架構(gòu)是松散耦合的，并且是圍繞服務(wù)構(gòu)建的。面向服務(wù)的架構(gòu)為它們提供了隔離特性。一個服務(wù)可能有許多數(shù)據(jù)庫服務(wù)器，它們的數(shù)據(jù)是互連的，但是它們只有一個外部接口。在外面，不可能知道這個服務(wù)背后的數(shù)據(jù)組織是如何構(gòu)建的。所以應(yīng)用服務(wù)器越來越多。這些應(yīng)用服務(wù)器從有大量數(shù)據(jù)的服務(wù)中聚合信息(每個服務(wù)背后都有一個數(shù)據(jù)庫或集群數(shù)據(jù)庫)，然后生成我們看到的所有亞馬遜頁面。這樣的服務(wù)就像插件一樣，形成一個開放的平臺，這樣團(tuán)隊的規(guī)模會更小，更靈活。注意，Amazon就是用這種架構(gòu)構(gòu)建的，它有成千上萬的服務(wù)器。系統(tǒng)軟件參數(shù)優(yōu)化在一定架構(gòu)的基礎(chǔ)上，要提高并發(fā)處理能力，需要調(diào)整服務(wù)器和web服務(wù)器的操作系統(tǒng)核心參數(shù)(tomcat參數(shù)、apache參數(shù)、Nginx參數(shù))來優(yōu)化其性能。操作系統(tǒng)優(yōu)化調(diào)整系統(tǒng)的核心參數(shù)、附加連接數(shù)和TCP/IP的超時設(shè)置。在Linux系統(tǒng)中:將以下核參數(shù)添加到/etc/sysctl.conf配置文件中:net.ipv4.tcp_syncookies=1net.ipv4.tcp_tw_reuse=1net.ipv4.tcp_tw_recycle=1net.ipv4.tcp_fin_timeout=5Tomcat服務(wù)器優(yōu)化增加并發(fā)連接數(shù)，調(diào)整存儲參數(shù)設(shè)置。1.JDK存儲優(yōu)化:當(dāng)應(yīng)用需要的內(nèi)存超過堆的最大值時，虛擬機(jī)會提示內(nèi)存溢出，導(dǎo)致應(yīng)用服務(wù)崩潰。因此，通常建議將最大堆值設(shè)置為最大可用內(nèi)存的80%。Tomcat默認(rèn)的可用內(nèi)存是128MB，對于較大的應(yīng)用來說不夠用，需要放大。Tomcat可以使用的默認(rèn)內(nèi)存是128MB。在Windows下，在/bin/catalina.bat文件下，Unix下，在/bin/catalina.sh文件前，添加以下設(shè)置:JAVA_OPTS='-Xms[初始化內(nèi)存大小]-Xmx[可使用的最大內(nèi)存]'這兩個參數(shù)值需要增加。例如:JAVA_OPTS='-Xms256m-Xmx512m'表示初始化內(nèi)存為256MB，可使用的最大內(nèi)存為512MB。2.連接器優(yōu)化:在tomcat配置文件server.xml的配置中，與連接數(shù)相關(guān)的參數(shù)有:MaxThreads:Tomcat使用線程來處理它收到的每個請求。該值表示Tomcat可以創(chuàng)建的最大線程數(shù)。默認(rèn)值為150。AcceptCount:指定當(dāng)處理請求的所有可用線程都被使用時，可以放入處理隊列的請求數(shù)，超過此數(shù)的請求將不會被處理。默認(rèn)值為10。sparethreads:Tomcat初始化時創(chuàng)建的線程數(shù)。默認(rèn)值為25。MaxSpareThreads:一旦創(chuàng)建的線程超過這個值，Tomcat就會關(guān)閉不再需要的套接字線程。默認(rèn)值為75。EnableLookups:是否反向查找域名；默認(rèn)值為true。為了提高處理能力，應(yīng)該將其設(shè)置為false。connectiontimeout:網(wǎng)絡(luò)連接超時，默認(rèn)值為60000，單位:毫秒。將其設(shè)置為0意味著它永遠(yuǎn)不會超時。這樣的設(shè)置有隱患。通?？梢栽O(shè)置為30000毫秒。MaxKeepAliveRequests:保留請求的數(shù)量，默認(rèn)值為100。BufferSize:輸入流緩沖區(qū)的大小，默認(rèn)值是2048字節(jié)。壓縮:壓縮傳輸，值為on/off/force，默認(rèn)值為off。與最大連接數(shù)相關(guān)的參數(shù)是maxThreads和acceptCount。如果希望增加并發(fā)連接數(shù)，應(yīng)該同時增加這兩個參數(shù)。web服務(wù)器允許的最大連接數(shù)也受*操作系統(tǒng)內(nèi)核參數(shù)設(shè)置的限制，通常Windows為2000左右，Linux為1000左右。Apache服務(wù)器優(yōu)化增加并發(fā)數(shù)，關(guān)閉不必要的模塊。因為apache消耗內(nèi)存比較大，所以應(yīng)該盡量輕。Apache在配置ContentType時可以盡量少支持，盡量少加載Module，以保證更高的系統(tǒng)消耗和執(zhí)行效率。同時配置apache和tomcat的組合，將靜態(tài)和動態(tài)頁面分開，apache處理靜態(tài)頁面，tomcat處理動態(tài)頁面。在處理靜態(tài)頁面、圖片、js等訪問時，可以考慮使用ligd代替Apache，這樣提供了更輕的重量和更高效的處理能力。Nginx服務(wù)器的優(yōu)化Worker_processes:該參數(shù)的值應(yīng)該等于cpu核心的數(shù)量，這樣可以最大化性能。如果nginx所在的服務(wù)器是2個雙核CPU，建議設(shè)置為4個。Web服務(wù)體系結(jié)構(gòu)的評估本文主要測試基于tomcat和nginx+tomcat的web服務(wù)器的處理性能，作為不同性能要求下架構(gòu)選擇的依據(jù)。測試環(huán)境網(wǎng)絡(luò)環(huán)境網(wǎng)絡(luò)帶寬m網(wǎng)。Ping數(shù)據(jù)包延遲:<0.1毫秒網(wǎng)絡(luò)拓?fù)涫疽鈭D服務(wù)器配置裝備硬件配置操作系統(tǒng)NginxIBMX3650CPU:英特爾至強(qiáng)E51502.66GHz雙核*2押金:4G千兆網(wǎng)卡Redhatlinuxas4Tomcat1惠普DL580G4CPU:英特爾至強(qiáng)3.40GHz4核*2押金:8G千兆網(wǎng)卡Redhatlinuxas5Tomcat2惠普DL580G4CPU:英特爾至強(qiáng)3.40GHz4核*2押金:8G千兆網(wǎng)卡Redhatlinuxas5測試1惠普DL580G5CPU:英特爾至強(qiáng)E73101.60GHz4核*2押金:4G千兆網(wǎng)卡Redhatlinuxas5測試2IBMX3650CPU:英特爾至強(qiáng)E51502.66GHz雙核*2押金:4G千兆網(wǎng)卡Redhatlinuxas4軟件環(huán)境操作系統(tǒng)網(wǎng)絡(luò)參數(shù)的優(yōu)化使用測試的每臺服務(wù)器都會在/etc/sysctl.conf的配置文件中添加以下核心參數(shù):net.ipv4.tcp_syncookies=1net.ipv4.tcp_tw_reuse=1net.ipv4.tcp_tw_recycle=1net.ipv4.tcp_fin_timeout=5Nginx設(shè)置主要配置如下:用戶；工作進(jìn)程4；error_log/usr/local/nginx/logs/nginx_error.log調(diào)試；PID/usr/local/nginx/logs/nginx.PID；worker_rlimit_nofile51200事件{使用epoll工人_連接51200；}{包括mime.typesdefault_type應(yīng)用程序/八位字節(jié)流；#charsetgb2312服務(wù)器名稱哈希桶大小128；client_header_buffer_size32klarge_client_header_buffers432k；在上發(fā)送文件；tcp_nopushonkeepalive_timeout1；tcp_nodelay打開；#gzipon#gzip_min_length1k#gzip_buffers416k#gzip__版；#gzip_comp_level2；#gzip_typestext/plainapplication/x-JavaScripttext/CSSapplication/XML；#gzip_varyon上游雄貓{服務(wù)器7:8081；服務(wù)器6:8081；#服務(wù)器1:8080；}計算機(jī)網(wǎng)絡(luò)服務(wù)器{聽81；server_name本地主機(jī)；proxy_redirectoff位置/{proxy_passtomcats}#后端Web服務(wù)器可以通過X-Forwarded-For獲取用戶的真實(shí)IP。#proxy_set_headerX-Forwarded-For$remote_addr；#位置/{#if($request_uri~*)。*\.(js|CSS|gif|jpg|JPEG|png|BMP|swf)$")#{#proxy_passsquid.abc#}#if($request_uri~*"^/view/(.*)$")#{#proxy_passsquid.abc#}#proxy_passweb.abc#}#定義日志格式log_format訪問'$remote_addr-$remote_user[$time_local]$request'"$status"$body_bytes_sent"$_referer""“$_user_agent”“$_x_forwarded_for”；#日志access_log/usr/local/nginx/logs/access.log訪問；#客戶端請求允許的單個文件的最大字節(jié)數(shù)client_max_body_size10m#緩沖代理從客戶端請求緩沖的最大字節(jié)數(shù)可以理解為在傳輸給用戶之前保存在本地?？蛻舳薩正文_緩沖區(qū)_大小128k#與后端服務(wù)器連接超時_發(fā)起握手和等待響應(yīng)超時proxy_connect_timeout600#連接成功后_等待后端服務(wù)器的響應(yīng)時間_實(shí)際上已經(jīng)進(jìn)入后端隊列進(jìn)行處理。proxy_read_timeout600#后端服務(wù)器數(shù)據(jù)返回時間—表示終端服務(wù)器必須在指定時間后傳輸所有數(shù)據(jù)。proxy_send_timeout600#Proxyrequestbuffer_這個buffer會存儲用戶的頭信息，供Nginx處理規(guī)則_一般情況下，只要頭信息可以保存。proxy_buffer_size8k#同上告訴Nginx可以使用多少空間來節(jié)省幾個緩沖區(qū)供單次使用。proxy_buffers432k#如果系統(tǒng)忙，可以申請更大的proxy_buffers*2官方推薦proxy_busy_buffers_size64k#代理緩存臨時文件大小代理_臨時_文件_寫入_大小64k}}Tomcat設(shè)置主要配置如下:Tomcat5.5MaxThread500最小螺紋25MaxSpareThread75Xmx1740M米Java環(huán)境使用jdk1.6_03啟動兩個Tomcat。使用jdk1.6啟動兩個客戶端的Tes測試T過程。試驗結(jié)果一臺TOMCATWEB服務(wù)器不客戶數(shù)量螺紋扣數(shù)請求數(shù)量間隔時間測試服務(wù)器使忙碌服務(wù)器負(fù)載期間平均速度完成請求結(jié)果描述一個一個500兩百萬0毫秒測試11.1G>15082秒1986件/秒106萬從第82秒開始，tomcat占用了1.1g內(nèi)存，但是CPU資源被tomcat耗盡，服務(wù)器負(fù)載急劇增加。最高顯示達(dá)到150，服務(wù)器停止響應(yīng)客戶端請求，于是客戶端請求速度急劇下降，誤包率100%，迫使測試中斷。22500兩百萬25毫秒測試11.7克<688秒每秒465次370,000從第280秒左右開始，tomcat占用的內(nèi)存達(dá)到Xmx規(guī)定的上限1.7g，Test1和Test2的請求速度急劇下降，出現(xiàn)包錯誤，包錯誤率超過>6%且仍在增加，測試終止。Tomcat拋出“Java.lang.outofmemoryerror:GCoverheadlimitexcess”異常。測試293秒123巴/秒200,000三2500兩百萬50毫秒測試11.7克<342秒每秒263次200,000從服務(wù)器上的第400秒開始，tomcat占用的內(nèi)存達(dá)到Xmx的上限1.7g，Test1和Test2的請求速度急劇下降，開始出現(xiàn)大量的包錯誤。422秒后，包錯誤率超過4.3%，并且還在增加。之前的誤包率在0.8%左右，測試終止。測試2413秒222件/秒200,000四2500兩百萬200毫秒測試11.7克<272秒727巴/秒280,000從第740秒左右開始，tomcat占用內(nèi)存達(dá)到Xmx的上限，Test1和Test2的請求速度急劇下降，開始出現(xiàn)大量的包錯誤。測試終止前，誤包率僅為0.008%。測試停止后，包錯誤率增加到1.7g%，并且還在增加。服務(wù)器負(fù)載小于2。測試274秒108件/秒190,000五2500兩百萬500毫秒測試11.7克<1195秒每秒72巴180,000從服務(wù)器端大約1595秒開始，tomcat占用內(nèi)存達(dá)到Xmx上限，Test1和Test2的請求速度急劇下降，開始出現(xiàn)大量錯誤包。在達(dá)到1.7g之前，誤包率只有0.08%。達(dá)到1.7G后，停止測試時，誤包率上升到2.3%，測試終止。測試2175秒每秒77巴160,000六2500三百萬1000毫秒測試11.7克<1662秒71巴/秒三百萬當(dāng)測試進(jìn)度達(dá)到80%左右時，tomcat1的內(nèi)存占用達(dá)到了Xmx的上限1.7g，但Test1和Test2的請求速度并沒有下降，直到600萬個請求全部完成，兩個客戶端丟棄了9個包，丟包率僅為0.003%，最長響應(yīng)時間為12.728秒。測試2651秒72巴/秒三百萬Ngx+2TOMCATWEB服務(wù)器不客戶數(shù)量螺紋扣數(shù)請求數(shù)量間隔時間測試服務(wù)器Tomcat占用內(nèi)存服務(wù)器負(fù)載期間平均速度已完成的請求數(shù)最大響應(yīng)時間平均響應(yīng)時間試驗結(jié)果一個2250一百五十萬0毫秒測試1第一代<237秒422巴/秒一百五十萬3005毫秒0.21毫秒300萬次請求全部完成，沒有任何錯誤。測試1第一代32秒458件/秒一百五十萬1244毫秒0.23毫秒22500兩百萬25毫秒測試11.4G<252秒390件/秒兩百萬4016毫秒0.27毫秒400萬次請求全部完成，沒有一次錯包。測試21.4G54秒每秒376次兩百萬4014毫秒0.27毫秒三2500三百萬50毫秒測試11.7克<2140秒每秒245次780,000從第1100秒左右開始，Tomcat1和Tomcat2占用Xmx規(guī)定的內(nèi)存高達(dá)1.7g，Test1和Test2的請求速度緩慢下降，但沒有出現(xiàn)錯誤包，因此人為終止測試。測試21.7克141秒每秒224次760,000四2500三百萬200毫秒測試11.7克<1160秒190件/秒770,000從第1800秒左右開始，Tomcat1和Tomcat2占用Xmx規(guī)定的內(nèi)存高達(dá)1.7g，Test1和Test2的請求速度緩慢下降，但沒有出現(xiàn)錯誤包，因此人為終止測試。測試21.7克863秒182巴/秒760,000五2500五百萬500毫秒測試11.7克<1475秒每秒93巴五百萬3000毫秒1.09毫秒測試完成，但Tomcat1和Tomcat2占用內(nèi)存1.7g，達(dá)到Xmx的指定上限，沒有錯誤包。測試21.7克565秒每秒88巴五百萬92987毫秒1.11毫秒六2500五百萬1000毫秒測試1968米<110149秒42巴/秒五百萬977毫秒2.02毫秒完成測試，沒有任何錯誤。測試2第一代10149秒42巴/秒五百萬944毫秒2.02毫秒Ngx+2個TOMCATWEB服務(wù)器+緩沖不客戶數(shù)量螺紋扣數(shù)請求數(shù)量間隔時間測試服務(wù)器Tomcat占用內(nèi)存服務(wù)器負(fù)載期間平均速度(巴/秒)已完成的請求數(shù)最大響應(yīng)時間平均響應(yīng)時間試驗結(jié)果一個2250一百五十萬0毫秒測試10.2G<164秒23437一百五十萬993毫秒0.04毫秒測試20.2G59秒25423一百五十萬372毫秒0.04毫秒22500兩百萬25毫秒測試10.4G<196秒10202兩百萬916毫秒0.10毫秒Nginx緩存打開后，完成了400萬個請求，分別有241個和216個錯誤包。測試20.4G94秒10361兩百萬908毫秒0.10毫秒三2500三百萬50毫秒測試10.4G<139秒7915三百萬015毫秒0.13毫秒Nginx緩存打開后，600萬次請求完成，沒有任何錯誤。測試20.2G34秒7812三百萬10234毫秒0.13毫秒四2500三百萬200毫秒測試10.4G<1一百二十秒2459三百萬3018毫秒0.40毫秒Nginx緩存打開后，600萬次請求完成，沒有任何錯誤。測試20.2G141秒2417三百萬384毫秒0.41毫秒五2500五百萬500毫秒測試10.4G<1531秒993五百萬3020毫秒1.00毫秒Nginx緩存打開后，1000萬次請求無一差錯地完成。測試20.2G555秒989五百萬394毫秒1.01毫秒六2500五百萬1000毫秒測試10.4G<110040秒498五百萬3020毫秒2.00毫秒Nginx緩存打開后，1000萬次請求無一差錯地完成。測試20.2G10038秒498五百萬78毫秒2.00毫秒注意:本測試中使用的jsp頁面只有100字節(jié)大小，因此測試期間的帶寬壓力可以忽略不計。在測試過程中，我們嘗試使用了100k大小的靜態(tài)頁面，結(jié)果顯示在千兆網(wǎng)絡(luò)下，無論是單個Tomcat還是Nginx+2Tomcat，最大請求速度都不超過1000頁/秒，網(wǎng)絡(luò)帶寬占用也達(dá)到了800M，接近千米網(wǎng)絡(luò)的上限。因此，在實(shí)際應(yīng)用中，網(wǎng)絡(luò)帶寬會對整個web服務(wù)產(chǎn)生很大的影響。測試結(jié)果分析系統(tǒng)參數(shù)的影響分析worker_processes參數(shù)對Nginx性能的影響測試過程中，當(dāng)worker_processes分別設(shè)置為8、4、2、1時，發(fā)現(xiàn)該參數(shù)對nginx的性能和服務(wù)器的資源消耗影響不大。相關(guān)數(shù)據(jù)顯示，這個參數(shù)的值應(yīng)該等于cpu核心的數(shù)量，才能發(fā)揮出最大的性能。在這個測試中，nginx所在的服務(wù)器是2個雙核CPU，所以最終測試設(shè)置為4個。MaxThread參數(shù)對tomcat并發(fā)性的影響在這個測試中，tomcat的MaxThread參數(shù)被設(shè)置為500。當(dāng)進(jìn)行13，000個并發(fā)測試時，tomcat啟動太多并發(fā)線程，會耗盡服務(wù)器cpu。雖然分析MaxThread可以提高tomcat的并發(fā)能力，但前提是保證服務(wù)器負(fù)載不會因為并發(fā)線程太多而急劇上升，從而停止響應(yīng)。-Xmx最大存儲值對Tomcat持續(xù)響應(yīng)高并發(fā)能力的影響在高并發(fā)請求的狀態(tài)下，有六個測試是因為tomcat的內(nèi)存達(dá)到了指定的最大值，導(dǎo)致響應(yīng)緩慢，直到內(nèi)存溢出停止響應(yīng)。因此，tomcat的最大內(nèi)存對Tomcat持續(xù)響應(yīng)高并發(fā)請求的能力影響很大。調(diào)整這個值應(yīng)該會增加Tomcat對高并發(fā)請求的響應(yīng)總數(shù)，從而延長WEB服務(wù)支持峰值的時間。每種架構(gòu)下的性能分析NGX+2Tomcat的最大并發(fā)低于單個Tomcat。NGX+2Tomcat的最快并發(fā)是每秒8980，單個Tomcat是每秒12986。分析可能是nginx所在服務(wù)器的性能導(dǎo)致的。當(dāng)單個tomcat配置最大內(nèi)存1.7g，并發(fā)請求持續(xù)時間超過1479/s，穩(wěn)定支持約240萬次響應(yīng)后，Tomcat內(nèi)存達(dá)到上限1.7，之后Tomcat響應(yīng)會急劇變慢，錯誤包急劇上升。在NGX+2tomcat的架構(gòu)下，當(dāng)兩只tomcat分別配置最大內(nèi)存1.7g時，在并發(fā)請求持續(xù)超過2900個/秒的情況下，可以穩(wěn)定支持約540萬次響應(yīng)。之后兩只Tomcats的內(nèi)存都會達(dá)到1.7的上限，響應(yīng)會急劇變慢，但是不會出現(xiàn)包錯誤。加上Nginx+2tomcat和cache，可以實(shí)現(xiàn)15000以上的并發(fā)處理能力。評估結(jié)果單只tomcat的處理能力約為每秒500枚。單個tomcat每秒可以穩(wěn)定地支持大約500個并發(fā)請求。Nginx+tomcat比單一的tomcat更穩(wěn)定，不容易出現(xiàn)錯包。通過擴(kuò)展Tomcat集群(增加Tomcat服務(wù)器)可以提高系統(tǒng)的并發(fā)性。當(dāng)單個tomcat超過并發(fā)能力時，其處理能力大大降低，出現(xiàn)大量錯誤包。但在各種測試下，Nginx+2Tomcat架構(gòu)雖然沒有錯包，但處理能力也會下降。單個tomcat每秒可以穩(wěn)定支持約500個并發(fā)請求，而Nginx+2Tomcat每秒可以支持約1000個并發(fā)請求。所以可以通過增加新的tomcat服務(wù)器來提高系統(tǒng)的并發(fā)性，但是當(dāng)tomcat的整體處理能力超過nginx時就無效了。NGX+2tomcat配置緩存后，靜態(tài)頁面的并發(fā)不再受tomcat限制，單個nginx的并發(fā)可以達(dá)到15000以上。配置緩存后，nginx+2tomcat的處理能力實(shí)測數(shù)據(jù)超過15000次/秒，而單個tomcat可以支持500次/秒。理論上，一組Nginx+30的Tomcat集群可以支持15000次/秒的并發(fā)處理。注:1.7G內(nèi)存分配給tomcat。配置選擇網(wǎng)絡(luò)帶寬只考慮門戶訪問的帶寬占用，后臺管理頁面等其他業(yè)務(wù)訪問與門戶訪問相差2-3個數(shù)量級，所以忽略這部分網(wǎng)絡(luò)流量占用。同時，考慮網(wǎng)絡(luò)帶寬利用率(70%)根據(jù)業(yè)務(wù)設(shè)計能力，每秒網(wǎng)絡(luò)流量=每秒WEB訪問流量。=(每次訪問占用的帶寬×每秒訪問次數(shù))/帶寬利用率=(200K*8*n)/0.7注:一般門戶的主頁大小>1M，平均200K/頁。我們把它作為平均值來計算。并發(fā)能力占用的網(wǎng)絡(luò)帶寬每秒100次228米每秒200次457米每秒500次1442米每秒1000次2286米和硬件配置選擇。硬件配置參考序列號產(chǎn)品功能參考模型，配置事務(wù)一個主機(jī)1.1數(shù)據(jù)庫服務(wù)器IBM系統(tǒng)x3850，4個處理器，每個處理器6個核心，共24個核心。尺寸是16G。SAS硬盤，硬盤大小587GB。4U機(jī)架，集成雙千兆以太網(wǎng)接口和兩個千兆光纖網(wǎng)卡。6845081.2網(wǎng)絡(luò)服務(wù)器IBM系統(tǒng)x3850，4個處理器，每個處理器6個核心，共24個核心。節(jié)省8G以上。SAS硬盤，硬盤大小587GB。4U機(jī)架，集成雙千兆以太網(wǎng)接口和兩個千兆光纖網(wǎng)卡。6845081.3辦公終端IBMSystemx3560，一個英特爾至強(qiáng)E5450處理器，存儲容量為2G，2U機(jī)架。326002網(wǎng)絡(luò)設(shè)備2.1負(fù)載平衡器RADWARE應(yīng)用負(fù)載均衡設(shè)備，型號:ODS-504，有，4個可選千兆電口，1G主存，500M處理能力(最大可通過許可證升級到4G)。2.2防火墻思科ASA5520防火墻并發(fā)性:20000網(wǎng)絡(luò)吞吐量:40安全過濾:225MB網(wǎng)絡(luò)端口:4個千兆以太網(wǎng)接口+1個快速接口用戶數(shù)量:無用用戶數(shù)量制約用戶。VPN支持:支持2.2配電盤QuidwayS3952P-EI傳輸速率:10Mbps/100Mbps/1000Mbps網(wǎng)絡(luò)標(biāo)準(zhǔn):IEEE802.1Q，IEEE8