【正文】 Test2 1863 秒 1482 條 /秒 276 萬 5 2 500 500萬 500毫秒 Test1 1 5475 秒 913 條 /秒 500 萬 93000毫秒 毫秒 完成測試，但 Tomcat Tomcat2 占用內(nèi)存到達 Xmx 指定上限 ，無錯包。 Test2 544 秒 3676 條 /秒 200 萬 45014毫秒 毫秒 3 2 500 300萬 50 毫秒 Test1 2 1140 秒 2445 條 /秒 278 萬 服務(wù)端從第 1100 秒左右開始， TomcatTomcat2 占用內(nèi)存到達 Xmx 指定上限 ，Test Test2 請求速度緩慢下降 ，但并無錯包，人為終止測試。 Test2 6351秒 472 條/秒 300萬 公開 內(nèi)部公開 機密 絕密 √ 11/17/2020 版權(quán)所有，侵權(quán)必究 All rights reserved 第 32頁 ,共 39頁 Page 32 , Total39 Nginx+2個 TOMCAT的 WEB服務(wù)器 NO 客戶端數(shù) 線程 數(shù) 請求次數(shù) 間隔時間 測試服 務(wù)器 Tomcat 占用內(nèi)存 服務(wù)器 負載 持續(xù)時 間 平均速度 完成請 求數(shù) 最大響應(yīng)時長 平均響應(yīng) 時長 測試結(jié)果 1 2 250 150萬 0 毫秒 Test1 1G 2 347 秒 4322 條 /秒 150 萬 93005毫秒 毫秒 300 萬次請求全部完成，無一錯 包。 Test2 744秒 1608條 /秒 119萬 5 2 500 200萬 500毫秒 Test1 1 1595秒 742 條/秒 118萬 服務(wù)端從第 1595 秒左右開始， tomcat 占用內(nèi)存到 達 Xmx指定上限 ， TestTest2請求速度急劇下降，開始出現(xiàn)大量錯包，達到 ，錯包率只有 %，達到 ，截止停止測試時，錯包率增長到 %， 測試終止 。 Test2 413秒 2922條 /秒 120萬 4 2 500 200萬 200毫秒 Test1 2 742秒 1727條 /秒 128萬 服務(wù)端從第 740 秒左右開始， tomcat 占用內(nèi)存到達 Xmx 指定上限 ， TestTest2 請求速度急劇下降，開始出現(xiàn)大量錯包， 測試終止 ，達到 前，錯包率只有 %，達到 后，截止停止測試時，錯包率增長到 %，且仍在在增加中。 tomcat拋出“ : GC overhead limit exceeded “異常。 公開 內(nèi)部公開 機密 絕密 √ 11/17/2020 版權(quán)所有，侵權(quán)必究 All rights reserved 第 31頁 ,共 39頁 Page 31 , Total39 測試結(jié)果 單個 TOMCAT的 WEB服務(wù)器 NO 客戶數(shù) 線程數(shù) 請求次數(shù) 間隔時間 測試服務(wù)器 占用內(nèi)存 服務(wù)器負載 持續(xù)時間 平均速度 完成請求 結(jié)果說明 1 1 500 200萬 0 毫秒 Test1 150 82 秒 12986條 /秒 106萬 從第 82 秒開始， tomcat 占用內(nèi)存 ，但 CPU 資源被 tomcat 耗盡，服務(wù)器負載急劇升高， top 顯示已達 150，服務(wù)器停止響應(yīng)客戶 端請求，客戶端請求速度急劇下降，錯包率 100%， 測試被迫中斷 。 } } 3. Tomcat設(shè)置 主要配置如下： ? ? MaxThread 500 公開 內(nèi)部公開 機密 絕密 √ 11/17/2020 版權(quán)所有，侵權(quán)必究 All rights reserved 第 30頁 ,共 39頁 Page 30 , Total39 ? MinSpareThread 25 ? MaxSpareThread75 ? Xmx 1740M 4. Java環(huán)境 ? 使用 Tomcat。 如果系統(tǒng)很忙的時候可以申請更大的 proxy_buffers 官方推薦 *2 proxy_busy_buffers_size 64k。 代理請求緩存區(qū) _這個緩存區(qū)間會保存用戶的頭信息以供 Nginx進行規(guī)則處理 _一般只要能保存下頭信息即可 proxy_buffer_size 8k。 連接成功后 _等候后端服務(wù)器響應(yīng)時間 _其實已經(jīng)進入后端的排隊之中等候處理 proxy_read_timeout 600。 緩沖區(qū)代理緩沖用戶端請求的最大字節(jié)數(shù) 可以理解為先保存到本地再傳給用戶 client_body_buffer_size 128k。 公開 內(nèi)部公開 機密 絕密 √ 11/17/2020 版權(quán)所有，侵權(quán)必究 All rights reserved 第 29頁 ,共 39頁 Page 29 , Total39 打日志 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 { use epoll。 pid /usr/local/nginx/logs/。 worker_processes 4。 3 Web服務(wù)架構(gòu) 評測 主要對基于 tomcat和 nginx+tomcat的 web服務(wù)器的處理性能進行測試，以作為不同性能要求下架構(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)頁面。 apache服務(wù)器優(yōu)化 加大并發(fā)數(shù)量和關(guān)閉不需要的模塊。如果要加大并發(fā)連接數(shù)，應(yīng)同時加大這兩個參數(shù)。 pression： 壓縮傳輸，取值 on/off/force，默認(rèn)值 off。 maxKeepAliveRequests： 保持請求數(shù)量，默認(rèn)值 100。設(shè)置為 0 表示永不超時，這樣設(shè)置有隱患的。 公開 內(nèi)部公開 機密 絕密 √ 11/17/2020 版權(quán)所有，侵權(quán)必究 All rights reserved 第 25頁 ,共 39頁 Page 25 , Total39 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 = 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ù)），以使其性能達到最優(yōu)化。 這樣 各種服務(wù)如插件一樣組成了一個開放的平臺， 這樣 團隊 的 規(guī)模 就會比較小，比較靈活 。 公開 內(nèi)部公開 機密 絕密 √ 11/17/2020 版權(quán)所有，侵權(quán)必究 All rights reserved 第 24頁 ,共 39頁 Page 24 , Total39 這樣就 有了越來越多的應(yīng)用服務(wù)器。 這種 架構(gòu)是松散耦合的，并且圍繞著服務(wù)進行構(gòu)建。上圖描述了 Struts框架的結(jié)構(gòu)，而下圖通過一個活動圖更具體描述接受請求直至返回響應(yīng)的整個過程 ： 公開 內(nèi)部公開 機密 絕密 √ 11/17/2020 版權(quán)所有，侵權(quán)必究 All rights reserved 第 23頁 ,共 39頁 Page 23 , Total39 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 語句進行了關(guān)聯(lián)。 WEB應(yīng)用 開發(fā) 架構(gòu)設(shè)計思路 1. 基于 MVC的三層應(yīng)用開發(fā)架構(gòu) 應(yīng)用開發(fā)實現(xiàn) MVC三層架構(gòu)進行 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)速度慢的問題。 CDN的全稱是 Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。 然后通過配置智能 DNS解析來 引導(dǎo)不同網(wǎng)絡(luò)的訪問用戶到對應(yīng)的網(wǎng)絡(luò)運營商的 web服務(wù)器。 公開 內(nèi)部公開 機密 絕密 √ 11/17/2020 版權(quán)所有，侵權(quán)必究 All rights reserved 第 19頁 ,共 39頁 Page 19 , Total39 網(wǎng)絡(luò)問題解決方案 你不可能要求所有 的使用人員，都和你的服務(wù)器在一個運營商的網(wǎng)絡(luò)內(nèi) ，而不同網(wǎng)絡(luò)之間訪問速度會很慢 ， 我們可以采用鏡像網(wǎng)站和 引入 CDN來解決這一問題 。 使用獨立的圖片服務(wù)器不但可以避免以上這個情況，更可以對不同的使用性質(zhì)的圖片設(shè)置不同的過期時間，以便同一個用戶在不同頁面 訪問相同圖片時不會再次從服務(wù)器（基于是緩存服務(wù)器）取數(shù)據(jù)，不但快速，而且還省了帶寬。 利用開源的 lsync監(jiān)聽某一目錄，如果目錄內(nèi)文件發(fā)生增、刪、改，利用 Rsync協(xié)議自動同步到多臺服務(wù)器。 而 NFS一般沒有這么巨大的規(guī)模。 目前 Google擁有超過 200個的GFS集群，其中有些集群的 PC數(shù)量超過 5000臺。 而 GFS則沒有這一特點，文件只能被集群系統(tǒng)中的 PC所訪問，而且這些 PC的操作系統(tǒng)一般是 Linux。客戶端先從Master上得到文件的 Metadata，根據(jù)要讀取的數(shù)據(jù)在文件中的位置與相應(yīng)的 TrunkServer通信，獲取文件數(shù)據(jù)。 GFS中文件備份成固定大小的 Trunk分別存儲在不同的 TrunkServer上，每個 Trunk有多份 (比如 3)拷