【正文】 網(wǎng)站的性能瓶頸分析網(wǎng)站的性能影響因素很多，下面主要從如下4個方面進行分析說明：1) 網(wǎng)絡負載a) 公網(wǎng)負載b) 內網(wǎng)負載2) WEB應用服務器性能a) CPUb) 存儲，I/O訪問c) 內存d) 并發(fā)TCP/IP 連接數(shù)3) 數(shù)據(jù)庫服務器性能a) 數(shù)據(jù)庫參數(shù)配置b) 服務器性能（CPU、內存、存儲）c) 數(shù)據(jù)結構的合理性4) 不同WEB應用的處理方式而對不同的性能瓶頸a) 對于靜態(tài)的網(wǎng)站：靜態(tài)的HTML頁面嚴格地由標準的 HTML標示語言構成，并不需要服務器端即時運算生成。對于靜態(tài)HTML的訪問瓶頸為：網(wǎng)絡帶寬、磁盤 I/O以及cache( 高速緩沖存儲器) 。通過Nginx實現(xiàn)反向代理服務器集群，同時搭建squid集群以作為靜態(tài)頁面和圖片的緩存。2) 采用高效的網(wǎng)絡文件共享策略，采用圖片服務器來實現(xiàn)頁面的圖片存儲。采用雙千兆交換機分別接在2臺防火墻上，當某臺設備或者網(wǎng)絡鏈路發(fā)生故障后，好設備自動接管已壞設備的工作，不影響網(wǎng)站的整體運行，根據(jù)業(yè)務及真實服務器的數(shù)量，交換機可以隨時增加。因此，對于同一個名字，不同的客戶機會得到不同的地址，它們也就訪問不同地址上的Web 服務器，從而達到負載均衡的目的。2. 通過硬件四層交換實現(xiàn)負載均衡在硬件四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優(yōu)秀的性能和很靈活的管理能力。當互聯(lián)網(wǎng)用戶請求 WEB 服務時， DNS 將請求的域名解析為反向代理服務器的 IP 地址，這樣 URL 請求將被發(fā)送到反向代理服務器，由反向代理服務器負責處理用戶的請求與應答、與后臺 WEB 服務器交互。Squid是由美國政府大力資助的一項研究計劃，其目的為解決網(wǎng)絡帶寬不足的問題，支持HTTP，HTTPS，F(xiàn)TP 等多種協(xié)議，是現(xiàn)在 Unix 系統(tǒng)上使用、最多功能也最完整的一套軟體。Squid 反向代理一般只緩存可緩沖的數(shù)據(jù)（比如 html 網(wǎng)頁和圖片等），而一些 CGI 腳本程序或者 ASP、JSP 之類的動態(tài)程序默認不緩存。在國內，已經有新浪博客、新浪播客、搜狐通行證、網(wǎng)易新聞、網(wǎng)易博客、金山逍遙網(wǎng)、金山愛詞霸、校內網(wǎng)、YUPOO相冊、豆瓣、迅雷看看等多家網(wǎng)站、頻道使用 Nginx 服務器。 5) 成本低廉Nginx為開源軟件，可以免費使用。 8) 節(jié)省帶寬支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。2) 同時還要配置session復制，也就是說其中任何一個tomcat的添加的session，是要同步復制到其它tomcat， 集群內的 tomcat都有相同的session，并為系統(tǒng)（包括 Apache 和 tomcat）設定 Session 超時時間。2） Nginx的緩存功能，支持了類似Squid 的緩存功能；緩存把URL 及相關組合當作 Key，用md5編碼哈希后保存；Nginx的Web緩存服務只能為指定URL或狀態(tài)碼設置過期時間，不支持類似Squid的PURGE指令，手動清除指定緩存頁面；采用MMAP實現(xiàn)，設置的緩存區(qū)大小不能超過物理內存+SWEB的值3） 基于mem cached的緩存nginx 對 memcached 有所支持，但是功能并不是特別之強，性能上還是非常之優(yōu)秀。}這個配置會將 指明到 memcached 的 abc 這個 key 去取數(shù)據(jù)。nginx會非常老實地將鏈接形式保存到文件系統(tǒng)中，這樣對于一個鏈接，可以很方便地查閱它在緩存機器上的緩存狀態(tài)和內容，也可以很方便地和別的文件管理器如 rsync等配合使用，它完完全全就是一個文件系統(tǒng)結構。永久緩存 緩存能隨意的寫入硬盤，因此允許昂貴的創(chuàng)建（expensivetocreate）數(shù)據(jù)來保持緩存，甚至能讓應用重啟。OSCache的特點:1) 緩存任何對象：你可以不受限制的緩存部分 jsp頁面或HTTP請求，任何java對象都可以緩存。 5) 緩存過期：你可以有最大限度的控制緩存對象的過期，包括可插入式的刷新策略（如果默認性能不能滿足需要時）。3） 自主開發(fā)的內存數(shù)據(jù)緩存服務a） 獨立進程方式的緩存服務對于一些常用的動態(tài)數(shù)據(jù)通過開發(fā)程序服務緩存在內存中，提供給其他子系統(tǒng)調用，如下面的數(shù)據(jù)就可以通過這樣方式進行緩存。這意味著，對一個靜態(tài)HTML 文檔發(fā)出訪問請求后，服務器端只是簡單地將該文檔傳輸?shù)娇蛻舳?。同時采用第三方開源的CMS 系統(tǒng)來實現(xiàn)網(wǎng)站內容的管理。為了提高靜態(tài)HTML的訪問效率，主要可以對以下幾個方面進行優(yōu)化：網(wǎng)絡帶寬、磁盤I/O以及cache(高速緩沖存儲器) 。但是多個數(shù)據(jù)庫意味著重復，除非你對數(shù)據(jù)進行了分離。如果正確 地完成該項工作，那么系統(tǒng)就可以擴展到2臺、3 臺甚至12臺服務器，并具備高可用性和穩(wěn)定性。另外還要確保擁有設計合理的、有用的關于安全、性能和穩(wěn)定性問題的設定，包括防止數(shù)據(jù)敗壞，其中很多設定都是非常重要的。2） NFS與GFS比較首先從它們的功能上進行分析。而GFS是Google為了滿足本公司迅速增長的數(shù)據(jù)處理要求而開發(fā)的文件系統(tǒng)。其次從結構上比較，NFS至少包括兩個主要部分：一臺服務器，以及至少一臺客戶機。Master 負責維護 GFS中的 Metadata，即文件名及其Trunk 信息。最后從規(guī)模上比較，HDFS只應用在大批量的數(shù)據(jù)共享上。2. 文件的多服務器自動同步使用Linux 文件系統(tǒng)事件。還有就是，對于緩存的時間上，亦可以做獨立的調節(jié)。2. CDN如果有足夠的投資，也可以采用CDN(內容分發(fā)網(wǎng)) ，把靜態(tài)內容（靜態(tài)頁面和圖片）進行CDN緩存，以減輕服務器壓力。 (也就是一個服務器的內容，平均分部到多個服務器上，服務器智能識別，讓用戶獲取離用戶最近的服務器，提高速度。iBATIS 是一個可以設計和實現(xiàn)更好的 Java 應用程序持久化層的框架。最終數(shù)據(jù)庫演變成一個非常龐大的共享資源。這些應用服務器從數(shù)據(jù)眾多的服務（每個服務背后都有數(shù)據(jù)庫或集群數(shù)據(jù)庫）中聚合信息。 操作系統(tǒng)優(yōu)化調整系統(tǒng)的內核參數(shù)，增大連接數(shù)及TCP/IP的超時設置。 Tomcat 默認可以使用的內存為128MB，在較大型的應用項目中，這點內存是不夠的，需要調大.Tomcat 默認可以使用的內存為 128MB,Windows 下,在文件/bin/，Unix 下，在文件/bin/ 的前面，增加如下設置： JAVA_OPTS=39。Xms256m Xmx512m39。默認值 150。默認值 25。為了提高處理能力，應設置為 falseconnnectionTimeout： 網(wǎng)絡連接超時，默認值 60000，單位：毫秒。 bufferSize： 輸入流緩沖大小，默認值 2048 bytes。web server 允許的最大連接數(shù)還受制于*作系統(tǒng)的內核參數(shù)設置，通常 Windows 是 2022個左右，Linux 是 1000 個左右。在處理靜態(tài)頁面或者圖片、js等訪問方面，可以考慮使用ligd 代替Apache ，它提供了更輕量級和更高效的處理能力 Nginx服務器的優(yōu)化worker_processes：該參數(shù)的值最好跟cpu核數(shù)相等，能夠發(fā)揮最大性能，如果nginx所在服務器為2顆雙核 cpu，則建議設定為4。error_log /usr/local/nginx/logs/ debug。 worker_connections 51200。 server_names_hash_bucket_size 128。 tcp_nopush on。 gzip_min_length 1k。 gzip_types text/plain application/xjavascript text/css application/xml。 server :8080。 location / { proxy_pass } 后端的Web 服務器可以通過XForwardedFor 獲取用戶真實IP proxy_set_header XForwardedFor $remote_addr。$status $body_bytes_sent $_referer 39。 允許客戶端請求的最大的單個文件字節(jié)數(shù) client_max_body_size 10m。 后端服務器數(shù)據(jù)回傳時間_就是在規(guī)定時間之內后端服務器必須傳完所有的數(shù)據(jù) proxy_send_timeout 600。 proxy緩存臨時文件的大小 proxy_temp_file_write_size 64k。Test1 288秒4765條/秒137萬22 500 200萬 25 毫秒 Test2 6 293秒4123條/秒120萬從第 280 秒左右開始，tomcat 占用內存到達 Xmx 指定上限，TestTest2 請求速度急劇下降，出現(xiàn)錯包，錯包率超過6%，且仍在增加，測試終止。 web 服務器負載小于 2。Test1 542 秒 3690 條/秒 200 萬 45016毫秒 毫秒2 2 500 200萬 25 毫秒Test2 2544 秒 3676 條/秒 200 萬 45014毫秒 毫秒400 萬次請求全部完成，無一錯包。Test1 968M 10149秒 492 條/秒 500 萬 9077毫秒 毫秒6 2 500 500萬 1000毫秒Test2 1G 110149秒 492 條/秒 500 萬9044毫秒 毫秒完成測試，無一錯包。Test1 5031秒 993 500 萬 3020 毫秒 毫秒5 2 500 500萬 500毫秒Test2 1 5055秒 989 500 萬 3394 毫秒 毫秒開啟 Nginx 緩存后，1000萬次請求全部完成，無一錯包。因此，實際應用中，網(wǎng)絡帶寬對整個 web服務的影響會非常大 測試結果分析1. 系統(tǒng)參數(shù)的影響分析1） worker_processes 參數(shù)對Nginx性能的影響測試過程中分別設定worker_processes為4 、1時發(fā)現(xiàn)，該參數(shù)對nginx性能影響不大，對服務器資源消耗也沒有太大影響，相關資料顯示，該參數(shù)的值最好跟cpu 核數(shù)相等，能夠發(fā)揮最大性能，本次測試nginx所在服務器為 2顆雙核cpu，因此最終測試設定為4。2. 各架構下的性能分析1) Nginx+2Tomcat的最大并發(fā)性低于單 Tomcat，Nginx+2Tomcat 最快為8980條/秒，單Tomcat為12986條/秒，分析可能是受 nginx所在服務器性能影響所致。2) Nginx+Tomcat比單個Tomcat更穩(wěn)定，不易出現(xiàn)錯包，可以通過擴充tomcat集群（新增tomcat服務器）來提升系統(tǒng)的并發(fā)能力單個tomcat 在超出并發(fā)能力的提求下，處理能力大大下降，并出現(xiàn)大量錯包，而采用Nginx+2Tomcat架構在各種測試下，均未出現(xiàn)錯包，但處理能力也會下降。配置了緩存后，nginx+2tomcat 萬次/ 秒，而單個tomcat 可以支撐500 次/秒，則從理論上計算一組Nginx+30 發(fā)處理。并發(fā)能力 占用的網(wǎng)絡帶寬100次/ 秒 228 M200次/ 秒 457 M500次/ 秒 1442 M1000次 /秒 2286 M 架構和硬件配置選型 硬件配置參考序號 產品功能 參考型號、配置 TPMC1 主機設備 數(shù)據(jù)庫服務器IBM System x3850 M2, 4 個處理器，每處理器為 6 核，共計24 核。684508 WEB 服務器IBM System x3850 M2, 4 個處理器，每處理器為 6 核，共計24 核。684508 管理終端 IBM System x3560，1 個 Intel Xeon E5450 處理器，內存大小 2G，2U 機架。1 臺生產數(shù)據(jù)庫，1 臺查詢數(shù)據(jù)庫1) Apache+n 個Tomcat（n=2）；2) Nginx+n 個Tomcat（n=2）；200~500次/秒注：同時配置緩沖3 臺 web 服務2 臺數(shù)據(jù)庫服務器2 臺緩存服務器1 臺 web 服務器裝 apache（nginx）；另 2 臺 web 服務器 tomcat；1 臺生產數(shù)據(jù)庫，1 臺查詢數(shù)據(jù)庫500 次/秒Nginx+n 個Tomcat（n=2）；注：同時配置緩沖n 臺 web 服務（n5）m 臺數(shù)據(jù)庫服務器2 臺緩存服務器2 臺負載均衡器1 臺 web 服務器裝 nginx；其他 web 服務器 tomcat；在 web 服務器4 臺的時侯可以考慮劃成多個nginx+tomcat 集群。2）當并發(fā)500時可以考慮增加tomcat服務器，當tomcat 請求。以下是兩種平臺擴容的方式： 增加服務器對于web的并發(fā)處理有瓶頸時，新增的web 服務器，把新增的web 服務器填加到Web服務器集群中，以增加WEB的并發(fā)處