最佳化招數
伺服器並發策略
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功能會對靜態檔案的吞吐率有負面影響。
動態腳本加速
加快腳本語言的執行速度；快取中間代碼（opcode）以供復用。
瀏覽器快取
減少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伺服器快取
這個第二點動態記憶體快取有區別，前者更指快取是否命中與否完全由應用程式決定，且快取方式也有套用來決定；而後者更指有web伺服器通過URL決定是否快取命中，比如靜態內容或者更新不太頻繁的動態內容就比較時候由其快取。
反向代理快取
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組件分離
從以下幾個方面來看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.放棄關係型資料庫，針對實際情況，讀寫要求極高時 資料庫擴展： 讀寫分離，按業務實施合理的垂直分區，對熱點表進行水平分區。
Web負載均衡
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
其他
內容分發和同步 WebDAV rsync etc
分散式檔案系統
分散式計算
十二 性能監控
工具列表：
1. MRTG 網卡流量報告，可以獲取實際頻寬（Max Speed），它便是從交換機接收連線埠獲得的最大接收速度，同時也是該主機的最大數據傳送速度。
2. apache ab 通過http進行壓力測試
3. *nix中的strace， 追蹤系統調用
4. 優秀的web server： apache， lighttpd， nginx
5. 反向代理:varnish
6. msyql工具： mysqlreport 資料庫狀態信息報表 mysql-proxy 資料庫反向代理 spock-proxy 分區反向代理
7. Nmon OS實時監控
8. Cacti 系統監控
9. 監控寶 回響時間監控
10. 分散式快取 memcached</seconds>
