【正文】 3) Nginx+2Tomcat配置了緩存后。單個tomcat能穩(wěn)定支持每秒500 左右的并發(fā)請求，而Nginx+2Tomcat能支持每秒1000左右的并發(fā)請求。4) 在Nginx+2tomcat，同時配置了緩存的情況下，可以達(dá)到 的并發(fā)處理能力 評測結(jié)果1) 單個tomcat 的處理能力在500條/秒左右單個tomcat能穩(wěn)定支持每秒500 左右的并發(fā)請求。2) ，在持續(xù)超過1479 條/ 秒的并發(fā)請求下，在穩(wěn)定支撐約240萬次響應(yīng)后，之后Tomcat響應(yīng)會急劇變慢，錯包急劇上升。3） Xmx最大內(nèi)存值對Tomcat能夠持續(xù)響應(yīng)高并發(fā)的影響持續(xù)高并發(fā)請求狀態(tài)下，有6次測試是因為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響應(yīng)高并發(fā)請求的總數(shù)，進(jìn)而延長WEB 服務(wù)能夠支撐峰值的時間。2） MaxThread參數(shù)對tomcat并發(fā)性的影響本次測試tomcat的 MaxThread參數(shù)設(shè)定為 500，進(jìn)行13000條/秒并發(fā)測試時，tomcat啟動并發(fā)線程過多，將服務(wù)器cpu耗盡。測試過程中曾嘗試過使用 100k大小靜態(tài)頁面，結(jié)果顯示在千兆內(nèi)網(wǎng)下，無論是單 Tomcat亦或是 Nginx+2Tomcat，請求速度最大均不超過 1000條 /秒，網(wǎng)絡(luò)帶寬使用已經(jīng)達(dá)到 800M，接近千 M內(nèi)網(wǎng)上限。Test1 10040 秒 498 500 萬 3020 毫秒 毫秒6 2 500 500萬 1000毫秒Test2 1 10038 秒 498 500 萬 78 毫秒 毫秒開啟 Nginx 緩存后，1000 萬次請求全部完成，無一錯包。Test1 1220秒 2459 300 萬 3018 毫秒 毫秒4 2 500 300萬 200毫秒Test2 1 1241秒 2417 300 萬 3384 毫秒 毫秒開啟 Nginx 緩存后，600萬次請求全部完成，無一錯包。大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第42 頁 Nginx+2個TOMCAT的WEB服務(wù)器+ 緩沖NO 客戶端數(shù) 線程 數(shù) 請求次數(shù) 間隔時間 測試服 務(wù)器 Tomcat 占用內(nèi)存 服務(wù)器 負(fù)載 持續(xù)時間 平均速度 (條/秒) 完成請 求數(shù) 最大響應(yīng) 時長 平均響應(yīng)時 長 測試結(jié)果Test1 64 秒 23437 150 萬 9993 毫秒 毫秒1 2 250 150萬0 毫秒 Test2 1 59 秒 25423 150 萬 3472 毫秒 毫秒 　Test1 196秒 10202 200 萬 9616 毫秒 毫秒2 2 500 200萬 25 毫秒Test2 1 194秒 10361 200 萬 9608 毫秒 毫秒開啟 Nginx 緩存后，400萬次請求全部完成，分別有 241 和 216 個錯包。Test1 5475 秒 913 條/秒 500 萬 93000毫秒 毫秒5 2 500 500萬 500毫秒Test2 15565 秒 898 條/秒 500 萬 92987毫秒 毫秒完成測試，但 TomcatTomcat2 占用內(nèi)存到達(dá) Xmx 指定上限 ，無錯包。Test1 1140 秒 2445 條/秒 278 萬 　 　3 2 500 300萬 50 毫秒Test2 21141 秒 2424 條/秒 276 萬 　 　服務(wù)端從第 1100 秒左右開始，TomcatTomcat2 占用內(nèi)存到達(dá) Xmx 指定上限 ，TestTest2 請求速度緩慢下降，但并無錯包，人為終止測試。大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第41 頁 Nginx+2個TOMCAT的WEB服務(wù)器NO 客戶端數(shù) 線程 數(shù) 請求次數(shù) 間隔時間 測試服 務(wù)器 Tomcat 占用內(nèi)存 服務(wù)器 負(fù)載 持續(xù)時 間 平均速度 完成請 求數(shù) 最大響應(yīng)時長 平均響應(yīng) 時長 測試結(jié)果Test1 1G 347 秒 4322 條/秒 150 萬 93005毫秒 毫秒1 2 250 150萬 0 毫秒Test1 1G 2322 秒 4658 條/秒 150 萬 21244毫秒 毫秒300 萬次請求全部完成，無一錯包。Test1 1595秒742 條/秒118萬52 500 200萬 500毫秒 Test2 1 1575秒737 條/秒116萬服務(wù)端從第 1595 秒左右開始，tomcat 占用內(nèi)存到達(dá) Xmx 指定上限，TestTest2 請求速度急劇下降，開始出現(xiàn)大量錯包，達(dá)到 前，錯包率只有 %，達(dá)到 后，截止停止測試時，錯包率增長到 %，測試終止。Test1 742秒1727條/秒128萬42 500 200萬 200毫秒 Test2 2 744秒1608條/秒119萬服務(wù)端從第 740 秒左右開始，tomcat 占用內(nèi)存到達(dá) Xmx 指定上限，TestTest2 請求速度急劇下降，開始出現(xiàn)大量錯包，測試終止，達(dá)到 前，錯包率只有 %，達(dá)到 后，截止停止測試時，錯包率增長到 %，且仍在在增加中。tomcat 拋出“: GC overhead limit exceeded “異常。大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第40 頁 測試結(jié)果 單個TOMCAT的WEB服務(wù)器NO客戶數(shù) 線程數(shù)請求次數(shù)間隔時間測試服務(wù)器占用內(nèi)存服務(wù)器負(fù)載持續(xù)時間平均速度完成請求 結(jié)果說明1 1 500 200萬 0 毫秒 Test1 150 82 秒 12986條/秒 106萬從第 82 秒開始，tomcat 占用內(nèi)存 ，但 CPU 資源被 tomcat 耗盡，服務(wù)器負(fù)載急劇升高，top 顯示已達(dá) 150，服務(wù)器停止響應(yīng)客戶端請求，客戶端請求速度急劇下降，錯包率 100%，測試被迫中斷。 }}3. Tomcat設(shè)置主要配置如下：? ? MaxThread 500大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第39頁? MinSpareThread 25? MaxSpareThread75? Xmx 1740M4. Java環(huán)境? 。 如果系統(tǒng)很忙的時候可以申請更大的proxy_buffers 官方推薦*2 proxy_busy_buffers_size 64k。 代理請求緩存區(qū)_ 這個緩存區(qū)間會保存用戶的頭信息以供 Nginx進(jìn)行規(guī)則處理_一般只要能保存下頭信息即可 proxy_buffer_size 8k。 連接成功后 _等候后端服務(wù)器響應(yīng)時間 _其實已經(jīng)進(jìn)入后端的排隊之中等候處理 proxy_read_timeout 600。 緩沖區(qū)代理緩沖用戶端請求的最大字節(jié)數(shù) 可以理解為先保存到本地再大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第38頁傳給用戶 client_body_buffer_size 128k。 打日志 access_log /usr/local/nginx/logs/ access。 39。 39。 location / { if ($request_uri ~* .*\.(js|css|gif|jpg|jpeg|png|bmp|swf)$) { proxy_pass } if ($request_uri ~* ^/view/(.*)$) { proxy_pass } proxy_pass } 定義日志格式 log_format access 39。 proxy_redirect off。 } server { listen 81。 server :8081。 gzip_vary on。 gzip_p_level 2。 gzip_buffers 4 16k。 gzip on。 keepalive_timeout 1。 sendfile on。 client_header_buffer_size 32k。 charset gb2312。} { include 。events 大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第36頁{ use epoll。pid /usr/local/nginx/logs/。worker_processes 4。大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第34頁3 Web服務(wù)架構(gòu)評測主要對基于tomcat和nginx+tomcat的web服務(wù)器的處理性能進(jìn)行測試，以作為不同性能要求下架構(gòu)選型的依據(jù) 測試環(huán)境 網(wǎng)絡(luò)環(huán)境1. 內(nèi)網(wǎng)帶寬? 千M內(nèi)網(wǎng)。Apache在配置 ContentType的時候可以盡量少支持，盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率同時配置apache和tomcat的組合使之能作到動靜分離，apache處理靜態(tài)頁面，tomcat處理動態(tài)頁面。大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第33頁 apache服務(wù)器優(yōu)化加大并發(fā)數(shù)量和關(guān)閉不需要的模塊。如果要加大并發(fā)連接數(shù)，應(yīng)同時加大這兩個參數(shù)。pression： 壓縮傳輸，取值 on/off/force，默認(rèn)值 off。大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第32頁maxKeepAliveRequests： 保持請求數(shù)量，默認(rèn)值 100。設(shè)置為 0 表示永不超時，這樣設(shè)置有隱患的。enableLookups： 是否反查域名，默認(rèn)值為 true。maxSpareThreads： 一旦創(chuàng)建的線程超過這個值， Tomcat 就會關(guān)閉不再需要的 socket 線程。minSpareThreads： Tomcat 初始化時創(chuàng)建的線程數(shù)。acceptCount： 指定當(dāng)所有可以使用的處理請求的線程數(shù)都被使用時，可以放到處理隊列中的請求數(shù)，超過這個數(shù)的請求將不予處理。這個值表示 Tomcat 可創(chuàng)建的最大的線程數(shù)。 表示初始化內(nèi)存為 256MB，可以使用的最大內(nèi)存為 512MB。例如： JAVA_OPTS=39。Xms【初始化內(nèi)存大小】 Xmx【可以使用的最大內(nèi)存】39。因此一般建議堆的最大值設(shè)置為可用內(nèi)存的最大值的 80%。Linux系統(tǒng)中：在/etc/： = 1 = 1大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第31頁 = 1 = 5 tomcat服務(wù)器優(yōu)化增大并發(fā)連接數(shù)，調(diào)整內(nèi)存參數(shù)的設(shè)置。 系統(tǒng)軟件參數(shù)優(yōu)化在一定的架構(gòu)基礎(chǔ)上，要提高并發(fā)處理能力則需要調(diào)整服務(wù)器的操作系統(tǒng)內(nèi)核參數(shù)、web服務(wù)器（tomcat 的參數(shù)、 apache的參數(shù)、Nginx的參數(shù)），以使其性能達(dá)到最優(yōu)化。這樣各種服務(wù)如插件一樣組成了一個開放的平臺，這樣團(tuán)隊的規(guī)模就會比較小，比較靈活。這樣就有了越來越多的應(yīng)用服務(wù)器。這種架構(gòu)是松散耦合的，并且圍繞著服務(wù)進(jìn)行構(gòu)建。上圖描述了Struts框架的結(jié)構(gòu)，而下圖通過一個活動圖更具體描述接受請求直至返回響應(yīng)的整個過程：大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第29頁大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第30頁2. 面向服務(wù)的應(yīng)用架構(gòu)面向服務(wù)的應(yīng)用架構(gòu)是指構(gòu)建可分布式的、去中心化的服務(wù)器平臺，以提供許多不同的應(yīng)用，數(shù)據(jù)庫被分成很多個小部分，圍繞每個部分都會創(chuàng)建一個服務(wù)接口(API), 并且該接口是訪問數(shù)據(jù)庫的唯一途徑。iBATIS 把對象和存儲過程或者使用 XML 描述符的 SQL 語句進(jìn)行了關(guān)聯(lián)。大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第26頁 WEB應(yīng)用開發(fā)架構(gòu)設(shè)計思路1. 基于MVC的三層應(yīng)用開發(fā)架構(gòu)應(yīng)用開發(fā)實現(xiàn)MVC三層架構(gòu)進(jìn)行web應(yīng)用開發(fā)，采用ibatis作為持久層框架，c3p0作為數(shù)據(jù)庫連接池。目前，國內(nèi)訪問量較高的大型網(wǎng)站如新浪、網(wǎng)易等，均使用 CDN網(wǎng)絡(luò)加速技術(shù)，雖然網(wǎng)站的訪問巨大，但無論在什么地方訪問都會感覺速度很快。從技術(shù)上全面解決由于網(wǎng)絡(luò)帶寬小、用戶訪問量大、網(wǎng)點分布不均等原因所造成的用戶訪問網(wǎng)站響應(yīng)速度慢的問題。大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第25頁CDN的全稱是 Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。然后通過配置智能DNS解析來引導(dǎo)不同網(wǎng)絡(luò)的訪問用戶到對應(yīng)的網(wǎng)絡(luò)運營商的web服務(wù)器。大型網(wǎng)絡(luò)平臺架構(gòu)設(shè)計方案第24頁 網(wǎng)絡(luò)問題解決方案你不可能要求所有的使用人員，都和你的服務(wù)器在一個運營商的網(wǎng)絡(luò)內(nèi)，而不同網(wǎng)絡(luò)之間訪問速度會很慢，我們可以采用鏡像網(wǎng)站和引入CDN來解決這一問題。使用獨立的圖片服務(wù)器不但可以避免以上這個情況，更可以對不同的使用性質(zhì)的圖片設(shè)置不同的過期時間，以便