站點性能優化
A. 如何進行網站WEB性能優化
採用瀏覽器緩存；圖片、JS的預載入；將腳本放在底部；精簡JS；精簡CSS；使用壓縮組件等方法進行網站WEB性能優化
B. 如何進行網站的性能調優
1、首先伺服器和域名DNS伺服器都使用國內的，這個對速度肯定影響最大；
2、如回果使用了HTTPS，那麼建議啟答用HTTP2；
3、靜態文件使用CDN；
4、低配雲主機（VPS）性能一般比虛擬主機更低，所以根據自己情況可以考慮用虛擬主機；
5、優化前端代碼，減少html節點數量；
還有比如dns-prefetch等等很多方式，都有一定好處，沒辦法一一列舉了。
C. 如何進行網站性能優化
內容頁面優化就一個要點：你的訪客要看到什麼內容你就做什麼內容。建議你以一個訪客的角度來看你自己的網站，內容是否完善、頁面是否好看、框架是否清晰……做好這些就算是內容優化了。
D. 什麼是網站性能優化技術
一、提高伺服器並發處理能力
我們總是希望一台伺服器在單位時間內能處理的請求越多越好，這也成了web伺服器的能力高低的關鍵所在。伺服器之所以可以同時處理多個請求，在於操作系統通過多執行流體系設計，使得多個任務可以輪流使用系統資源，這些資源包括CPU、內存以及I/O等。這就需要選擇一個合適的並發策略來合理利用這些資源，從而提高伺服器的並發處理能力。這些並發策略更多的應用在apache、nginx、lighttpd等底層web server軟體中。
二、Web組件分離
這里所說的web組件是指web伺服器提供的所有基於URL訪問的資源，包括動態內容，靜態網頁，圖片，樣式表，腳本，視頻等等。這些資源在文件大小，文件數量，內容更新頻率，預計並發用戶數，是否需要腳本解釋器等方面有著很大的差異，對不同特性資源採用能充分發揮其潛力的優化策略，能極大的提高web站點的性能。例如：將圖片部署在獨立的伺服器上並為其分配獨立的新域名，對靜態網頁使用epoll模型可以在大並發數情況下吞吐率保持穩定。
三、資料庫性能優化和擴展。
Web伺服器軟體在資料庫方面做的優化主要是減少訪問資料庫的次數，具體做法就是使用各種緩存方法。也可以從資料庫本身入手提高其查詢性能，這涉及到資料庫性能優化方面的知識本文不作討論。另外也可以通過主從復制，讀寫分離，使用反向代理，寫操作分離等方式來擴展資料庫規模，提升資料庫服務能力。
四、Web負載均衡及相關技術
負載均衡是web站點規模水平擴展的一種手段，實現負載均衡的方法有好幾種包括基於HTTP重定向的負載均衡，DNS負載均衡，反向代理負載均衡，四層負載均衡等等。
對這些負載均衡方法做簡單的介紹：基於HTTP重定向的負載均衡利用了HTTP重定向的請求轉移和自動跳轉功能來實現負載均衡，我們熟悉的鏡像下載就使用這種負載均衡。DNS負載均衡是指在一個DNS伺服器中為同一個主機名配置多個IP地址，在應答DNS查詢時返回不同的解析結果將客戶端的訪問引到不同的機器上，使得不同的客戶端訪問不同的伺服器，從而達到負載均衡的目的。反向代理負載均衡也叫七層負載均衡，這是因為反向代理伺服器工作在TCP七層結構的第七層(應用層)，它通過檢查流經的HTTP報頭，根據報頭內的信息來執行負載均衡任務。四層負載均衡是基於NAT技術的負載均衡，它將一個Internet上合法注冊的IP地址映射為多個內部伺服器的IP地址，對每次TCP連接請求動態使用其中一個內部IP地址，達到負載均衡的目的。此外，還有工作在數據鏈路層(第二層)的直接路由方式下的負載均衡，它通過修改數據包目標MAC地址來實現。以及，基於IP隧道的負載均衡，在這種方式下可以將實際伺服器根據需要部署在不同的地域，並根據就近訪問的原則來轉移請求，CDN服務便是基於IP隧道技術來實現的。
Web負載均衡在擴展web伺服器規模的同時也給web站點性能優化提供了一個更大更復雜也更靈活自由的平台，基於該平台性能優化的策略包括共享文件系統，內容分發與同步，分布式文件系統，分布式計算，分布式緩存等等。
五、web緩存技術
web緩存技術被認為是減輕伺服器負載、降低網路擁塞、增強萬維網可擴展性的有效途徑，其基本思想是利用客戶訪問的時間局部性(Temporal Locality)原理，將客戶訪問過的內容在Cache中存放一個副本，當該內容下次被訪問時，不必連接到駐留網站或重新計算生成，而是由Cache中保留的副本提供。Web緩存可以帶來如下的好處：
(1) 減少網路流量，從而減輕網路擁塞;這是因為緩存避免了一部分HTTP請求。
(2) 降低客戶訪問延遲，其主要原因有：①已緩存的內容，客戶可以緩存獲取而不是從伺服器獲取或重新計算生成，從而減小了傳輸延遲縮短了響應時間;②沒有被緩存的內容由於網路擁塞及伺服器負載的減輕而可以較快地被客戶獲取;
(3) 由於客戶的部分或者全部請求內容可以從通過緩存獲取，從而減輕了遠程伺服器負載。
(4) 如果由於伺服器故障或網路故障造成伺服器無法響應客戶請求，客戶可以從緩存中獲取緩存的內容副本，使得web站點服務的魯棒性(Robustness)得到了加強。
可以看出web緩存能給web站點帶可觀的性能提升。其實在用戶發出請求到一幅完整的網頁呈現在用戶面前這一過程中緩存無處不在，下面是web性能優化時常用的緩存技術，你會發現緩存被廣泛應用在各個環節。
瀏覽器緩存：瀏覽器一般會在用戶文件系統中創建一個目錄，用於存放緩存文件，並給每個緩存文件打上必要的標記，比如過期時間等。這些標記主要用於瀏覽器和伺服器之間的緩存協商。
Web伺服器緩存：一個URL在一段較長時間內對應一個唯一的響應內容，比如靜態內容或者更新不太頻繁的動態內容，web伺服器可將響應內容緩存起來，下次web伺服器便可以在收到請求後立即拿出事先緩存好的響應內容並返回給瀏覽器。
代理伺服器緩存：暴露在互聯網中與後端的web伺服器通過內部網路相連的前端伺服器稱為反向代理伺服器，建立在反向代理伺服器上的緩存稱為反向代理緩存。暴露在互聯網中與後端的web客戶端通過內部網路相連的前端伺服器稱為正向代理伺服器，建立在正向代理伺服器上的緩存稱為正向代理緩存。代理伺服器緩存位於客戶端和web伺服器之間，可以將它看做二者之間的一個中繼站。它的存在可以改善客戶端的訪問速度、提升web server的服務能力、安全性等等。
總共分析總結了五種技術，主要希望能夠對web server性能優化這塊提供一個整體的認識。後續會專門就web緩存技術發表一些自己的看法。
E. 高性能Web站點的優化招數
1.這里的吞吐率特指Web伺服器單位時間內處理的請求。
2.壓力測試的前提：1>並發用戶數 2>總請求數 3>請求資源描述
3.用戶平均請求等待時間主要用戶衡量伺服器在一定並發用戶數的情況下，對於單個用戶的伺服器質量；而伺服器平均請求處理時間與前者相比，則用於衡量伺服器的整體服務質量，它其實就是吞吐率的倒數。
4.對http header中標記為Connection: Keep-Alive的請求，開啟web伺服器的長連接支持。減少系統調用accept的次數，即減少建立連接的開銷。
5.老調重彈，進程，內核級線程和用戶級線程在不同情況下的優劣。IO模型，mmap（內村映射），直接IO，例如sendfile syscall以及非同步IO等。多路IO復用（select， poll，epoll and kqueue etc）
6.伺服器並發策略
1> 一個進程處理一個連接，非阻塞IO。穩定性強，但context switch的開銷隨http request遞增而快速增長。
2> 一個內核級線程處理一個連接，非阻塞IO，多進程多線程混合方式。Context switch的問題依然存在。理論上可以支持更多的並發連接。
3>一個進程處理多個連接，非阻塞IO。（epoll， kqueue）lighttpd, nginx。支持並發性能強勁。 上述情況的適用范圍不能一刀切，而且這里都是指單機並發，需根據實際情況（實際並發數）來選擇。通常，在並發用戶數較大的情況下，Web伺服器使用什麼樣的並發策略，是影響最大並發數的關鍵。 在實際應用中，動態內容緩存可能是使用得最多的技術，但是並不見得所有的動態內容都適合使用網頁緩存，緩存帶來的性能提升恰恰與有些動態數據實時交互的需求形成矛盾，這就是一個權衡。
1. 緩存動態生成的html代碼。
2. 把動態內容靜態化，直接緩存整個html文件。這樣就可以直接訪問緩存。這時的更新策略：
1>在數據更新時重新生成靜態化內容 2>定時重新生成靜態化內容
3. 使用SSI（server side include）進行局部靜態化。但web server的SSI功能會對靜態文件的吞吐率有負面影響。 減少http請求，充分利用瀏覽器的緩存。而webapp通過http協議（更具體位置就是http header）來與瀏覽器協商，那些東東瀏覽器可以使用其緩存即可。
1. Last-Modified/If-Modified-Since
2. ETag/If-None-Match
3.Expires + Cache-Control: max-age=<seconds>
1和2需要瀏覽器和webserver交互後，有伺服器端通知瀏覽器是否使用瀏覽器緩存，而3則是在過期前直接使用瀏覽器緩存，這樣就直接kill掉了http request。同時還需注意，在使用SSI的內容中，由於整個頁面是伺服器動態生成的，所以Last-Modified標記在不同的Web伺服器中有不同的生成方法。 Web伺服器隱藏在代理伺服器之後。這種代理機制稱為反向代理（Reverse proxy），同時，實現這種機制的伺服器便成為反向代理伺服器。隱藏在反向代理伺服器之後的Web伺服器，我們習慣稱它為後端伺服器（Back-end server），當然，反向代理伺服器就被稱為前端伺服器(Front-end server)。
引入反向代理伺服器的目的之一就是基於緩存的加速。我們可以將內容緩存在反向代理伺服器上，所有緩存機制的實現仍然採用HTTP/1.1協議。
緩存命中率和後端吞吐率的理想技術模型
緩存丟失率=（活躍內容數/（實際吞吐率×平均緩存有效期））×100%
緩存命中率= 1-緩存丟失率 後端吞吐率= 活躍內容數/平均緩存有效期
緩存命中率= （1-（後端吞吐率/實際吞吐率））×100%
後端吞吐率 = （1 – 緩存命中率）×實際吞吐率
結論： 1. 活躍內容數和平均緩存有效期一定的情況下，緩存命中率與實際吞吐率成正比。
2. 實際吞吐率和平均緩存有效期一定的情況下，緩存命中率與活躍內容數成反比。
3. 活躍內容數和實際吞吐率一定的情況下，緩存命中率與平均緩存有效期成正比。
4. 活躍內容數一定的情況下，後端吞吐率與平均緩存有效期成反比。
5. 平均緩存有效期一定的情況下，後端吞吐率與活躍內容數成正比。
6. 緩存命中率的變化不一定會影響後端吞吐率。
7. 後端吞吐率的變化不一定會影響緩存命中率。
ESI – Edge Side Include類似與SSI，但不在webserver端組裝內容，而是在http代理伺服器上組裝內容，包括反向代理。在處理只有局部更新動態內容時AJAX是更好的原則，它不依賴與底層webserver的實現，但ESI的優勢在於再有多個後端伺服器的情況下，變可以避免多個後端的重復組裝，減少總工作量。 從以下幾個方面來看Web組件的差異：
1. 文件大小
2. 文件數量
3. 內容更新頻率
4. 預計並發用戶數
5. 是否需要腳本解釋器
6. 是否涉及大量CPU計算
7. 是否訪問資料庫
8. 訪問資料庫的主要操作是讀還是寫
9. 是否包含RPC
對每種類型的Web組件採取不同的優化方式（一種或多種）：
1. 是否使用epoll模型
2. 是否使用sendfile() syscall
3. 是否使用非同步IO
4. 是否支持HTTP持久連接（http keep-alive）
5. 是否需要opcode緩存
6. 是否使用動態內容緩存以及有效期為多長
7. 是否使用Web伺服器緩存以及有效期為多長
8. 是否使用瀏覽器緩存以及有效期為多長
9. 是否使用反向代理緩存以及有效期為多長
10. 是否使用負載均衡策略
按照Web組件的不同類型將其放在不同的二級域名/機器/不同類型的WebServer
同時，還需考慮到不同的瀏覽器對同一個域名下的訪問有多大並發數限制，而使用多個域名。
IE6，7 2(http/1.1)
IE8 6(http/1.1)
Firefox2 2(http/1.1)
Firefox3 6(http/1.1)
發揮各自的潛力
對於動態內容：開啟opcode緩存，使用足夠快的CPU，足夠大的內存，多進程以及與資料庫保持高速連接
對於靜態內容：支持epoll，非阻塞IO，非同步IO，使用sendfile，單進程（對於IO密集型任務，多進程無法發揮優勢），使用高速磁碟，使用RAID
對於image, css and script分配合理設置其過期時間(expires) 1.合理的執行計劃，包括合理使用索引
2.使用慢查詢分析工具，找出執行很慢的sql並優化之。
3.合理的資料庫緩存，索引緩存，數據緩存等
4.更具實際需求選擇合理的資料庫引擎或資料庫
5.反範式化設計，對查詢帶來優化，但增加寫和更新的工作量。
6.放棄關系型資料庫，針對實際情況，讀寫要求極高時 資料庫擴展： 讀寫分離，按業務實施合理的垂直分區，對熱點表進行水平分區。 DNS負載均衡
需要DNS服務商提供該功能，且DNS記錄存在緩存，無法及時修改，帶來更新延遲。
反向代理負載均衡
HTTP重定向和DNS解析在請求的調度上體現在「轉發」上，而其則體現在「轉移」。
任何對於實際伺服器的http請求都必須經過調度器；調度器必須等待實際伺服器的http響應，並將它反饋給用戶。
由於調度策略在自己手中，就可以使用諸如按照權重進行調度等策略。也可以對個應用伺服器進行健康監控，對無效伺服器不在把請求轉移給它；還可以實現sticky sessions。
作為負載均衡調度器的反向代理伺服器在擴展上的制約，反向代理伺服器的處理能力制約了整個集群的處理能力，其次，容易出現單點故障
IP負載均衡
Netfilter+ IPVS
用iptables修改Netfilter規則，進行基於IP的tcp包轉發，也即調度。 IPVS（IP Virtual Server）也成為LVS(Linux Virtual Server)。
兩者結合的具體策略有 1. LVS + NAT
2. LVS + DR
F. 網站性能優化怎麼辦
一、前端優化
網站性能優化是一個很綜合的話題，涉及到伺服器的配置和網站前後端程序等各個方面，我只是從實際經歷出發，分享一下自己所嘗試過的網站性能優化方法。之所以在標題上掛一個web2.0，是因為本文更偏重於中小網站的性能優化，我所使用的系統也是典型web2.0的LAMP架構。
首先講講前端的優化，用戶訪問網頁的等待時間，有80%是發生在瀏覽器前端，特別是頁面和頁面中各種元素（圖片、CSS、javascript、 flash…）的下載之上。因此在很多情況下，相對於把大量的時間花在艱苦而繁雜的程序改進上，前端的優化往往能起到事半功倍的作用。雅虎最近將內部使用的性能測試工具yslow向第三方公開，並發布了著名的網站性能優化的十三條規則，建議你下載並安裝yslow，並作為測評網站優化效果的工具。下面我挑其中特別有價值的具體說明一下優化的方法：
對於第一次訪問您網站，尚未在瀏覽器cache中緩存您網站內容的用戶，我們可以做的事情包括：
1）減少一個頁面訪問所產生的http連接次數
對於第一次訪問你網站的用戶，頁面所產生的http連接次數是影響性能的一個關鍵瓶頸。
對策：
- 盡量簡潔的頁面設計，最大程度減少圖片的使用，通過放棄一些不必要的頁面特效來減少javascript的使用。
- 使用一些優化技巧，比如利用圖片的背景位移減少圖片的個數；image map技術；使用Inline images將css圖片捆綁到網頁中。
- 盡量合並js和css文件，減少獨立文件個數。
2) 使用gzip壓縮網頁內容
使用gzip來壓縮網頁中的靜態內容，能夠顯著減少用戶訪問網頁時的等待時間（據說可達到60%）。主流的web伺服器都支持或提供gzip壓縮，如果使用apache伺服器，只需要在配置文件中開啟 mod_gzip（apache1.x）或mod_deflate(apache2.x)即可。凡是靜態的頁面，使用gzip壓縮都能夠顯著提高伺服器效率並減少帶寬支出，注意圖片內容本身已經是壓縮格式了，務必不要再進行壓縮。
3）將CSS放在頁面頂端，JS文件放在頁面底端
CSS的引用要放在html的頭部header中，JS文件引用盡量放在頁面底端標簽的後面，主要的思路是讓核心的頁面內容盡早顯示出來。不過要注意，一些大量使用js的頁面，可能有一些js文件放在底端會引起一些難以預料的問題，根據實際情況適當運用即可。
4）使JS文件內容最小化
具體來說就是使用一些javascript壓縮工具對js腳本進行壓縮，去除其中的空白字元、注釋，最小化變數名等。在使用gzip壓縮的基礎上，對js內容的壓縮能夠將性能再提高5%。
5）盡量減少外部腳本的使用，減少DNS查詢時間
不要在網頁中引用太多的外部腳本，首先，一次dns的解析過程會消耗20-120毫秒的時間；其次，如果在頁面中引用太多的外部文件（如各種廣告、聯盟等代碼），可能會因為外部文件的響應速度而將你的網站拖得很慢。如果不得不用，那麼就盡量將這些腳本放在頁腳吧。不過有一點需要提及，就是瀏覽器一般只能並行處理同一域名下的兩個請求，而對於不同子的域名則不受此限制，因此適當將本站靜態內容（css,js）放在其他的子域名下（如 static.xxx.com）會有利於提高瀏覽器並行下載網頁內容的能力。
對於您網站的經常性訪問用戶，主要的優化思路就是最大限度利用用戶瀏覽器的cache來減少伺服器的開銷。
1）在header中添加過期時間(Expires Header)
在header中給靜態內容添加一個較長的過期時間，這樣可以使用戶今後訪問只讀取緩存中的文件，而不會與伺服器產生任何的交互。不過這樣做也存在一些問題，當圖片、CSS和js文件更新時，用戶如果不刷新瀏覽器，就無法獲得此更新。這樣，我們在對圖片、css和js文件修改時，必須要進行重命名，才能保證用戶訪問到最新的內容。這可能會給開發造成不小的麻煩，因為這些文件可能被站點中的許多文件所引用。flickr提出的解決辦法是通過url rewrite使不同版本號的URL事實上指向同一個文件，這是一個聰明的辦法，因為url級別的操作效率是很高的，可以給開發過程提供不少便利。
要理解為什麼這樣做，必須要了解瀏覽器訪問url時的工作機制：
a. 第一次訪問url時，用戶從伺服器段獲取頁面內容，並把相關的文件（images,css,js…）放在高速緩存中，也會把文件頭中的expired time,last modified, ETags等相關信息也一同保留下來。
b. 用戶重復訪問url時，瀏覽器首先看高速緩存中是否有本站同名的文件，如果有，則檢查文件的過期時間；如果尚未過期，則直接從緩存中讀取文件，不再訪問伺服器。
c. 如果緩存中文件的過期時間不存在或已超出，則瀏覽器會訪問伺服器獲取文件的頭信息，檢查last modifed和ETags等信息，如果發現本地緩存中的文件在上次訪問後沒被修改，則使用本地緩存中的文件；如果修改過，則從伺服器上獲取最新版本。
我的經驗，如果可能，盡量遵循此原則給靜態文件添加過期時間，這樣可以大幅度減少用戶對伺服器資源的重復訪問。
2）將css和js文件放在獨立外部文件中引用
將css和js文件放在獨立文件中，這樣它們會被單獨緩存起來，在訪問其他頁面時可以從瀏覽器的高速緩存中直接讀取。一些網站的首頁可能是例外的，這些首頁的自身瀏覽可能並不大，但卻是用戶訪問網站的第一印象以及導向到其他頁面的起點，也可能這些頁面本身使用了大量的ajax局部刷新及技術，這時可以將 css和js文件直接寫在頁面中。
3）去掉重復的腳本
在IE中，包含重復的js腳本會導致瀏覽器的緩存不被使用，仔細檢查一下你的程序，去掉重復引用的腳本應該不是一件很難的事情。
4）避免重定向的發生
除了在header中人為的重定向之外，網頁重定向常在不經意間發生，被重定向的內容將不會使用瀏覽器的緩存。比如用戶在訪問www.xxx.com，伺服器會通過301轉向到www.xxx.com/，在後面加了一個「/」。如果伺服器的配置不好，這也會給伺服器帶來額外的負擔。通過配置apache的 alias或使用mod_rewrite模塊等方法，可以避免不必要的重定向。
還有一些，比如使用CDN分發機制、避免CSS表達式等、避免使用ETags等，因為不太常用，這里就不再贅述了。
做完了上述的優化，可以試著用yslow測試一下網頁的性能評分，一般都可以達到70分以上了。
當然，除了瀏覽器前端和靜態內容的優化之外，還有針對程序腳本、伺服器、資料庫、負載的優化，這些更深層次的優化方法對技術有更高的要求。本文的後半部分將重點探討後端的優化。
二、後端優化
上次寫完web2.0網站前端優化篇之後，一直想寫寫後端優化的方法，今天終於有時間將思路整理了出來。
前端優化可以避免我們造成無謂的伺服器和帶寬資源浪費，但隨著網站訪問量的增加，僅靠前端優化已經不能解決所有問題了，後端軟體處理並行請求的能力、程序運 行的效率、硬體性能以及系統的可擴展性，將成為影響網站性能和穩定的關鍵瓶頸所在。優化系統和程序的性能可以從以下的方面來入手：
1）apache、mysql等軟體的配置的優化
盡管apache和mysql等軟體在安裝後使用的默認設置足以使你的網站運行起來，但是通過調整mysql和apache的一些系統參數，還是可以追求更高的效率和穩定性。這個領域中有很多專業的文章和論壇（比如： http://www.mysqlperformanceblog.com/），要想掌握也需要進行深入的研究和實踐，這里就不重點討論了。
2）應用程序環境加速
這里僅以我最常應用的php開發環境為例，有一些工具軟體可以通過優化PHP運行環境來達到提速的目的，其基本原理大致是將PHP代碼預編譯並緩存起來，而不需要改變任何代碼，所以比較簡單，可以將php的運行效率提升50%以上。比較常用的免費php加速工具有：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ http://turck-mmcache.sourceforge.net）、php accelebrator(www.php-accelerator.co.uk)，還有收費的Zend Performance Suite
3）將靜態內容和動態內容分開處理
apache是一個功能完善但比較龐大的web server，它的資源佔用基本上和同時運行的進程數呈正比，對伺服器內存的消耗比較大，處理並行任務的效率也一般。在一些情況下，我們可以用比較輕量級的web server來host靜態的圖片、樣式表和javascript文件，這樣可以大大提升靜態文件的處理速度，還可以減少對內存佔用。我使用的web server是來自俄羅斯的nginx，其他選擇方案還包括lighttpd和thttpd等。
4）基於反向代理的前端訪問負載均衡
當一台前端伺服器不足以應付用戶訪問時，通過前端機實現web訪問的負載均衡是最快速可行的方案。通過apache的mod_proxy可以實現基於反向代理的負載均衡，這里推薦使用nginx做代理伺服器，處理速度較apache更快一些。
5）應用緩存技術提高資料庫效能，文件緩存和分布式緩存
資料庫訪問處理並發訪問的能力是很多網站應用的關鍵瓶頸，在想到使用主從結構和多farm的方式構建伺服器集群之前，首先應該確保充分使用了資料庫查詢的緩存。一些資料庫類型（如mysql的innoDB）自身內置對緩存的支持，此外，還可以利用程序方法將常用的查詢通過文件或內存緩存起來。比如通過 php中的ob_start和文件讀寫函數可以很方便的實現文件形式的緩存，而如果你擁有多台伺服器，可以通過memcache技術通過分布式共享內存來對資料庫查詢進行緩存，不僅效率高而且擴展性好，memcache技術在livejournal和Craigslist.org等知名網站應用中都得到了檢驗。
6）伺服器運行狀態的檢測，找到影響性能的瓶頸所在
系統優化沒有一勞永逸的方法，需要通過檢測伺服器的運行狀態來及時發現影響性能的瓶頸，以及可能存在的潛在問題，因為網站的性能，永遠取決於木桶中的短板。可以編寫一些腳本來檢測web服務的運行，也有一些開源的軟體也提供了很好的功能
7）良好的擴展架構是穩定和性能的基礎
一些技巧和竅門可以幫你度過眼前的難關，但要想使網站具備應付大規模訪問的能力，則需要從系統架構上進行徹底的規劃，好在很多前人無私的把他們架構
網站的經驗分享給我們，使我們可以少走甚多彎路。我最近讀到的兩篇有啟發的文章：
- 從LiveJournal後台發展看大規模網站性能優化方法
- Myspace的六次重構
最後不得不提到程序編碼和資料庫結構對性能的影響，一系列糟糕的循環語句，一個不合理的查詢語句、一張設計不佳的數據表或索引表，都足以會使應用程序運行的速度成倍的降低。培養全局思考的能力，養成良好的編程習慣，並對資料庫運行機制有所了解，是提高編程質量的基礎。
G. 如何優化Web網站性能
這個問題不難!是抄優化網站性能，不是提高用戶體驗，那麼能增加資金預算的話，硬體方面提高配置，比如用更快的CPU，加大內存，使用高速硬碟，增加帶寬等等。
軟體方面，對程序代碼和資料庫進行優化，網站頁面生成靜態頁，減少對資料庫和伺服器的壓力，使用存儲過程等等。
H. 如何對網站進行性能優化
一、刪除功能：重要數據偽刪除，刪除校驗用戶（避免A用戶可以刪除任何人數據）。文件上傳預覽刪除功能不能做伺服器文件刪除，不要為了節省伺服器資源給用戶留下介面。如果要資源有限，那麼在刪除的時候也需要做用戶校驗（文件命名或文件路徑關聯用戶ID等）
二、發簡訊:基本上沒有人願意自己和簡訊運營商直接對接簡訊業務，一般都是通過第三方簡訊服務商購買簡訊。在用戶主動獲取簡訊的時候前端做圖片驗證碼校驗，後端做發送量，發送間隔校驗（圖片驗證碼是可以被機識別的）。做簡訊日誌記錄，這些日誌可以為前面的後台校驗提供數據，系統運行期間的各種好處就不一一舉例了。重要功能做語音驗證碼，比如注冊送現金的活動，簡訊驗證碼可以被識別
三、頁面數據獲取：用戶平凡的刷新數據會加大伺服器壓力，當然誰也擋不住用戶刷新是吧，但是減少主動刷新次數也是一個減小伺服器壓力的方法，咱不能自己坑自己吧，(Table頁切換做校驗，有數據就不再拉取等等)
四、前端靜態資源做CDN，可以提高用戶訪問速度，減少伺服器壓力
五、用戶輸入做SQL注入，javascript腳本注入
六、用到的Ajax請求：做ajax加攔截器，通過消息頭過濾掉非ajax的地址欄訪問，（誰然不一定能全部攔截，但是攔掉一部分小白還是可以得，總不能是個人就能攻擊吧）
七、用戶輸入數據校驗，輸入文字長度，數字輸入大小，int 、long等數據類型合理使用，(積分兌換的時候用戶只有1積分，你讓他輸入兌換積分，你輸入21000000000，int 接收的時候，超出了范圍成了負數1永遠大於負數)，還有一點很重要，你的任何校驗都不要依靠前端，畢竟前端是為用戶的體驗而生的，為了自己的安全還是多寫點後台校驗吧，
八、異常捕獲：不要將異常信息拋給用戶，首先不美觀，其次這些錯誤信息中可能含有SQL錯誤，通過這些sql可以了解到你的資料庫結構
九、前端數據獲取的時候減少不必要欄位輸出，java面向對象，表數據面向對象，本來頁面只需要兩個數據，結果你返回了一個實體，前端可已查看到你資料庫表結構，多看幾個頁面那麼你的資料庫設計就給了人家了呢
十、用戶信息加密傳輸，一定不要把重要數據留在客戶端，泄密重要信息的責任是要你承擔的哦
十一、 現在越來越多人使用阿里雲伺服器，做客戶項目的時候伺服器是客戶購買的，當然阿里雲賬戶客戶也有，你的配置文件不加密客戶就能看見你的系統配置，結合上面的搞搞你的資料庫，那你的產品還有什麼秘密，至於代碼，你覺得他值錢么
十二、 前端JS 腳本 和頁面分離，壓縮或加密，不要你的團隊倖幸苦苦開發的唯美的頁面和效果，被人家一個ctrl+s拿去回家研究了，何況你的js中還有大量的邏輯
十三、 線程安全:
1、synchronized同步 （有序性、可見性），
2、使用生產者消費者模式，(喚醒notify()，等待wait())
3、volatile同步（可見性，非有序性，只在無基礎數據的賦值操作，直接操作主內存，減少主內存復制到工作內存的cpu消耗）
十四、 資料庫讀寫分離的時候要注意個別業務讀也要讀在主庫上（避免主從同步失敗或延時）
I. 什麼是網站性能優化，為什麼要優化
網路搜索一個問題時有至少都有幾十萬條數據，如果不做優化，都沒人會看到你的網站，你說這種情況下網站能帶來什麼效益呢?
J. 網站性能優化
這個要看你網站的主題還有你的目的啊，才能對症下葯，是吧，不能直接根據域名判斷吧。優化建議，推薦到www.jqqnet.com，看看，希望能幫點忙給你