nginx並不能從根本上提升服務器性能，如果是單體應用可能還會導致服務器性能下降，nginx更偏向於解決服務器擴容和分佈式系統部署，此處比較幾個常用的緩存
以下均爲轉載
Varnish、Squid、Ngx_cache性能測試對比
一：概括：
varnish與squid是在業內比較主流的web緩存加速技術，與傳統的web加速技術apache cache和nginx cache相比，做的更專業，性能更出衆！對於兩款軟件的簡介這裏就不多做介紹，網上有很多的資料與文檔，感興趣的同學可以自己看看。下面就一起看看他們的性能和抗壓情況吧！
1.工作原理與性能對比
(1)Varnish：
Varnish緩存加速原理：Varnish把數據緩存到服務器的內存中(通過-s file選項也可以先存到磁盤中)，用戶訪問時直接從內存中的緩存數據讀取，因此非常快。它可以設置0～60秒的精確緩存時間，不過32位的機器支持的緩存文件最大爲2 GB。Varnish的狀態機設計不僅巧妙，結構也很清晰，利用二叉堆管理緩存文件，即可達到隨時刪除的目的。
優點：varnish由於是採用多線程的方式運行，所以它的系統資源利用率要比squid強（squid採用單進程耗1核CPU），但在高併發下它的CPU、Mem、IO資源消耗也比squid嚴重。varnish的TCP連接與釋放比squid更快一些，因此在同樣的負載情況下支持更高的併發連接數。由於客戶是從內存中讀取緩存，因此比squid硬盤級的緩存速度更快。Varnish支持管理端口通過正則表達式來清楚緩存。Varnish總體來說適合高質量大流量的緩存加速(如靜態頁面和小文件等)。
(2)Squid：
Squid緩存加速原理：支持正向代理、透明代理、反向代理，它採用硬盤級的緩存技術，將用戶的請求文件緩存到本地磁盤中能夠緩存更多的內容，每G磁盤空間需要32M的內存，因此512M內存的系統能支持16G的磁盤緩存。
優點：squid採用單進程使用單核CPU，利用資源的問題上不如varnish合理，但同時在資源消耗上要比varnish小。由於是採用硬盤做緩存，所以數據的完整性上要比varnish強，因爲緩存到varnish內存上的數據是易失的，一旦varnish進程hang、crash或者重啓，緩存的數據都會從內存中釋放出來，此時所有請求都會發送到後端服務器，在高併發下會給後端的server造成很大的壓力。Squid很多人說命中比較低，所以需要多個服務器同時來緩存才能發揮作用。總體來說squid緩存的體系比較大成本高，適合大文件、流媒體等數據的緩存。
(3)Nginx_cache:
Nginx緩存加速原理：nginx在0.7.48版本以後開始支持類似squid的緩存功能，他通過proxy_cache模塊與fastcgi_cache模塊實現對web的靜態頁面加速和對fastcgi動態程序的緩存加速，nginx_cache緩存是把URL及相關組合當作Key，用md5編碼哈希後保存在硬盤上，所以它可以支持任意URL鏈接，同時也支持404/301/302這樣的非200狀態碼。同時nginx_cache將緩存到的數據直接存放到內存文件系統中加快訪問速度，同時內存文件系統與磁盤做硬link，不分熱點與非熱點數據，內存佔用率不是最優的。Nginx_cache把熱點文件分層緩存，一般使用時將cache目錄放置與內存文件系統中。
優點：Nginx已經具備Squid所擁有的Web緩存加速功能、通過ngx_cache_purge模塊清除指定URL緩存的功能。而在性能上，Nginx對多核CPU的利用，勝過Squid不少。另外，在反向代理、負載均衡、健康檢查、後端服務器故障轉移、Rewrite重寫、易用性上，Nginx也比Squid強大得多。這使得一臺Nginx可以同時作爲“負載均衡服務器”與“Web緩存服務器”來使用。
二：測試要求：
(1)要求與環境：
要求：對Nginx源站中的一個大小爲20K左右的靜態頁面進行壓力測試。
環境(硬件)：緩存服務器爲HP DL360 G5，內存：8G，CPU：單顆Intel(R) Xeon CPU E5506 2.13GHz 4核，硬盤：160G scsi接口。
環境(軟件)：緩存和源站系統均爲centOS 6.4 64位，squid版本爲2.6-STABLE23(官方最穩定)，varnish版本爲最新的3.0.2。nginx
源站：Nginx服務器，HP DL160 G6，內存8G，CPU:單顆 Intel Xeon CPU E5504 2.00GHz 4核，硬盤：160G scsi接口。
預計結果：在大量的論壇和web緩存加速的博文中，都說varnish比squid更強,支持的併發更高，性能更穩定。而nginx_cahce並不是專業的緩存加速軟件，理論上並沒有squid和varnish支持的好。根據varnish的特點（小文件、靜態頁面加速效果更好），理論上應該是varnish的特點更適合這個應用場景。但我們來看看實際是不是這樣呢？
下面我們就來利用web壓力測試軟件webbench來進行測試吧。
如圖，-c選項是客戶端的請求個數，-t爲時間，默認單位是秒。如圖意義爲，在30秒內對http://10.20.216.56/tz.htm進行1000次HTTP(GET)請求。Speed的值爲每分鐘訪問頁面的數量，Requests爲成功和失敗訪問的次數。
(2)測試結果：
|
緩存類型
|
30秒內500個客戶端請求
|
30秒內1000個客戶端請求
|
30秒內3000個客戶端請求
|
30秒內5000個客戶端請求
|
30秒內10000個客戶端請求
|
|
Squid2.6-STABLE23-ufs存儲
|
40.5萬次\100%
81.0萬
pages/min
|
40.7萬次\100%
81.4萬pages/min
|
40.8萬次\100%
81.7萬pages/min
|
40.5萬次\100%
81.1萬pages/min
|
40.6萬\99.9%
82.5萬pages/min
|
|
Squid2.6-STABLE23-coss存儲
|
44.2萬次\100%
86.1萬
pages/min
|
45.2萬次\100%
87.1萬
pages/min
|
44.3萬次\100%
89.3萬
pages/min
|
44.5萬次\100%
87.3萬
pages/min
|
44.1萬\99.9%
86.3萬
pages/min
|
|
Varnish-3.0.2
|
70.1萬次\100%
140萬pages/min
|
69.7萬次\100%
139.4萬pages/min
|
69.9萬\99.66%
140.2萬pages/min
|
70.2萬\99.26%
141.5萬pages/min
|
68.9萬\93.88%
148.5萬pages/min
|
|
Nginx_cache
|
60.8萬次\100%
121.6萬
pages/min
|
63.1萬次\100%
125.9萬
pages/min
|
67.5萬\99.99%
134.5萬
pages/min
|
72.7萬\99.99%
145.5萬
pages/min
|
73.4萬\99.82%
148.7萬
pages/min
|
|
Nginx源站
|
66.1萬次\100%
133.0萬
pages/min
|
63.4萬次\100%
127.0萬
pages/min
|
80.1萬\98.8%
162.1萬
pages/min
|
82.2萬\96.9%
169.7萬
pages/min
|
89.4萬\93.8%
191.6萬
pages/min
|
壓力情況綜上表所述：
1.Varnish：在500-1000併發情況下，varnish的性能明顯好於對手，很好的起到了緩存加速的目的並且大大減輕了源站的壓力，但隨着訪問量的增加從3000以上併發開始，varnish的性能開始下滑，訪問成功率下降、404錯誤失敗增加、系統CPU負載同樣嚴重。並沒有預期的效果那麼出衆。
Varnish的關鍵配置文件如下：
varnishd -u varnish -g varnish -f /usr/local/varnish/etc/vcl.conf -a 10.20.216.56:80 -s file,/usr/local/varnish/cache/varnish_cache.data,4G -w 5,51200,30 -t 3600 -T 10.20.216.56:3000
-s：制定存儲類型和存儲目錄文件大小。
-w：min,max,timeout 指定varnish的工作線程數。
-t：指定默認ttl值。
2.Squid：基於ufs的傳統存儲方式，隨着訪問量的增高性能並沒有明顯的變化(系統負載的情況也比較平穩)，可是在10000的高併發下還是出現了失敗的情況；基於coss的適合小文件緩存的存儲方式，效果比ufs稍稍的強一些但提升的不是很大，大概提升不到10%。總體來看，squid不論是採用哪種存儲方式存數據，加速的效果都沒有源站好，但分擔負載的作用還是能充分體現的。和預期結果還是有偏差。
Squid的關鍵配置如下：
cache_mem 1024 MB #指定squid可以使用的內存的理想值
cache_swap_low 80 #緩存空間允許使用的最小空間百分比
cache_swap_high 90 #緩存空間允許使用的最大空間百分比
maximum_object_size_in_memory 100 KB #內存緩存的最大文件
cache_dir ufs /usr/local/squid/cache 20480 16 256 max-size=204800 #設置磁盤緩存工作方式，工作路徑，大小單位MB，一級HASH的目錄數量，二級HASH的目錄數量。
3.Nginx_cache：nginx的proxy_cache緩存加速模塊，雖然在500-1000左右併發的情況下沒有varnish卓越，但在高併發3000以上的情況下性能還是比預期的要好，無論是在成功相應的請求次數上還是速度上，都比varnish和squid的性能更強更穩定。
Nginx_cache關鍵配置如下：
worker_processes 4; #指定進程的個數
worker_rlimit_nofile 65535; #文件句柄數，和系統單進程打開的文件數相同
events
{
use epoll;
worker_connections 65535; #定義單個進程的連接數
}
server_names_hash_bucket_size 128; #共同控制保存服務器名的HASH表
proxy_connect_timeout 5; #nginx和後端服務器連接超時時間
proxy_read_timeout 60; #連接成功後等候後端服務器響應時間，其實已經進入後端的排隊等候處理
proxy_send_timeout 5; #後端服務器數據回傳時間，就是在規定的時間內後端服務器必須傳完所有的數據
proxy_buffer_size 16k; #代理請求緩存去，該緩存去間保存用戶的頭信息，以供nginx進行規則處理一般只要保能保存下頭信息即可
proxy_buffers 4 64k; #告訴nginx保存單個用的幾個buffer 最大用多少空間
proxy_busy_buffers_size 128k; #高負載下緩衝大小(proxy_buffers*2)
proxy_temp_file_write_size 128k; #設置緩存文件夾大小，如果大於該值，將從upstream 服務器傳遞請求，而不緩衝到磁盤上
概括總結：
由於需求是針對於50K以下的小文件，誰抗壓能力更強加速效果更好，並且保障5個9以上的高可用性，爲用戶提供更好的體驗。在500~1000左右的併發下，varnish的表現更出色。而在3000以上的併發情況下，Nginx_cache出乎意料，比varnish和squid的整體性能都要強。因此：
3000以下併發：varnish
3000以上併發：Nginx_cache
PS:以上測試結果的數據受系統環境和應用程序參數的影響，因此不一定很準確，僅供參考。