Ⅰ 為什麼Nginx下的gzip不壓縮javascript了
因為Nginx下的gzip默認不壓縮javascript、圖片等靜態資源文件
可以通過gzip_types指定需要壓縮的MIME類型
gzip on;
gzip_types text/plain application/x-javascript text/css text/javascript;
MIME(Multipurpose Internet Mail Extensions)多用途互聯網郵件擴展類型。是設定某種擴展名的文件用一種應用程序來打開的方式類型，當該擴展名文件被訪問的時候，瀏覽器會自動使用指定應用程序來打開。多用於指定一些客戶端自定義的文件名，以及一些媒體文件打開方式。
常見MIME類型參考：
格式前面為後輟名，後面為對應的MIME型（例如：rar application/x-rar-compressed 表示。RAR對應的是application/x-rar-compressed ）
{ ".apk", "application/vnd.android.package-archive" },
{ ".asp", "application/x-asap" },
{ ".flv", "flv-application/octet-stream" },
{ ".gif", "image/gif" },
{ ".gz", "application/x-gzip" },
{ ".htc", "text/x-component" },
{ ".htm", "text/html" },
{ ".html", "text/html" },
{ ".ico", "image/x-icon" },
{ ".jpeg", "image/jpeg" },
{ ".jpg", "image/jpeg" },
{ ".js", "application/x-javascript" },
{ ".mht", "message/rfc822" },
{ ".mhtml", "message/rfc822" },
{ ".mp3", "audio/mpeg" },
{ ".mp4", "video/mp4" },
{ ".mpa", "video/mpeg" },
{ ".mpeg", "video/mpeg" },
{ ".mpg", "video/mpeg" },
{ ".mpg4", "video/mp4" },
{ ".pdf", "application/pdf" },
{ ".png", "image/png" },
{ ".ppt", "application/vnd.ms-powerpoint" },
{ ".pptx", "application/vnd.openxmlformats-officedocument.presentationml.presentation" },
{ ".pqf", "application/x-cprplayer" },
{ ".rf", "image/vnd.rn-realflash" },
{ ".rgb", "image/x-rgb" },
{ ".rmvb", "audio/x-pn-realaudio" },
{ ".shtml", "magnus-internal/parsed-html" },
{ ".swf", "application/x-shockwave-flash" },
{ ".tif", "image/tiff" },
{ ".wml", "text/vnd.wap.wml" },
{ ".xhtm", "application/xhtml+xml" },
{ ".xhtml", "application/xhtml+xml" },
{ ".xla", "application/vnd.ms-excel" },
{ ".xlc", "application/vnd.ms-excel" },
{ ".xll", "application/x-excel" },
{ ".xlm", "application/vnd.ms-excel" },
{ ".xls", "application/vnd.ms-excel" },
{ ".xlsx", "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" },
{ ".xlt", "application/vnd.ms-excel" },
{ ".xlw", "application/vnd.ms-excel" },
{ ".xm", "audio/x-mod" },
{".xml","text/plain"},
{".xml","application/xml"},[1]
{ ".zip", "application/zip" },
{ ".json", "application/json" },
Ⅱ nginx 緩存怎麼都在tmp
nginx緩存cache的5種方案
1、傳統緩存之一（404）
這個辦法是把nginx的404錯誤定向到後端，然後用proxy_store把後端返回的頁面保存。
配置：
location / {
root /home/html/;#主目錄
expires 1d;#網頁的過期時間
error_page 404 =200 /fetch$request_uri;#404定向到/fetch目錄下
}
location /fetch/ {#404定向到這里
internal;#指明這個目錄不能在外部直接訪問到
expires 1d;#網頁的過期時間
alias /html/;
proxy_store會將文件保存到這目錄下
proxy_passhttp://www.jb51.net/;#後端upstream地址，/fetch同時是一個代理
proxy_set_header Accept-Encoding '';#讓後端不要返回壓縮（gzip或deflate）的內容，保存壓縮後的內容會引發亂子。
proxy_store on;#指定nginx將代理返回的文件保存
proxy_temp_path /home/tmp;#臨時目錄，這個目錄要和/home/html在同一個硬碟分區內
}
使用的時候還有要注意是nginx要有許可權往/home/tmp和/home/html下有寫入文件的許可權，在linux下nginx一般會配
置成nobody用戶運行，這樣這兩個目錄就要chown nobody，設成nobody用戶專用，當然也可以chmod
777，不過所有有經驗的系統管理員都會建議不要隨便使用777。
2、傳統緩存之二（!-e）
原理和404跳轉基本一致，但更簡潔一些：
location / {
root /home/html/;
proxy_store on;
proxy_set_header Accept-Encoding '';
proxy_temp_path /home/tmp;
if ( !-f $request_filename )
{
proxy_passhttp://www.jb51.net/;
}
}
可以看到這個配置比404節約了不少代碼，它是用!-f來判斷請求的文件在文件系統上存不存在，不存在就proxy_pass到後端，返回同樣是用proxy_store保存。
兩種傳統緩存都有著基本一樣的優點和缺點：
缺點1：不支持帶參數的動態鏈接，比如read.php?id=1，因為nginx只保存文件名，所以這個鏈接只在文件系統下保存為
read.php，這樣用戶訪問read.php?id=2時會返回不正確的結果。同時不支持http://www.jb51.net/這種形式的首頁和
二級目錄http://www.jb51.net/download/，因為nginx非常老實，會將這樣的請求照鏈接寫入文件系統，而這個鏈接顯然是一
個目錄，所以保存失敗。這些情況都需要寫rewrite才能正確保存。
缺點2：nginx內部沒有緩存過期和清理的任何機制，這些緩存的文件會永久性地保存在機器上，如果要緩存的東西非常多，那就會撐暴整個硬碟空間。為此可以使用一個shell腳本定期清理，同時可以撰寫php等動態程序來做實時更新。
缺點3：只能緩存200狀態碼，因此後端返回301/302/404等狀態碼都不會緩存，假如恰好有一個訪問量很大的偽靜態鏈接被刪除，那就會不停穿透導致後端承載不小壓力。
缺點4：nginx不會自動選擇內存或硬碟作為存儲介質，一切由配置決定，當然在當前的操作系統里都會有操作系統級的文件緩存機制，所以存在硬碟上也不需要過分擔心大並發讀取造成的io性能問題。
nginx傳統緩存的缺點也是它和squid等緩存軟體的不同之特色，所以也可看作其優點。在生產應用中它常常用作和squid的搭檔，squid對
於帶?的鏈接往往無法阻擋，而nginx能將其訪問攔住，例如：http://jb51.net/?和http://jb51.net/在squid上會
被當做兩個鏈接，所以會造成兩次穿透；而nginx只會保存一次，無論鏈接變成http://jb51.net/?1還是http://jb51.net
/?123，均不能透過nginx緩存，從而有效地保護了後端主機。
nginx會非常老實地將鏈接形式保存到文件系統中，這樣對於一個鏈接，可以很方便地查閱它在緩存機器上的緩存狀態和內容，也可以很方便地和別的文件管理器如rsync等配合使用，它完完全全就是一個文件系統結構。
這兩種傳統緩存都可以在linux下將文件保存到/dev/shm里，一般我也是這么做的，這樣可以利用系統內存來做緩存，利用內存的話，清理過期內
容速度就會快得多。使用/dev/shm/時除了要把tmp目錄也指向到/dev/shm這個分區外，如果有大量小文件和目錄，還要修改一下這個內存分區
的inode數量和最大容量：
mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm
上面的命令在一台有3G內存的機器上使用，因為/dev/shm默認最大內存是系統內存的一半就是1500M，這條命令將其調大成2500M，
同時shm系統inode數量默認情況下可能是不夠用的，但有趣的是它可以隨意調節，這里調節為480000保守了點，但也基本夠用了。
3、基於memcached的緩存
nginx對memcached有所支持，但是功能並不是特別之強，性能上還是非常之優秀。
location /mem/ {
if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" )
{
set $memcached_key "$1";
memcached_pass 192.168.1.2:11211;
}
expires 70;
}
這個配置會將http://jb51.net/mem/abc指明到memcached的abc這個key去取數據。
nginx目前沒有寫入memcached的任何機制，所以要往memcached里寫入數據得用後台的動態語言完成，可以利用404定向到後端去寫入數據。
4、基於第三方插件ncache
ncache是新浪兄弟開發的一個不錯的項目，它利用nginx和memcached實現了一部分類似squid緩存的功能，我並沒有使用這個插件的經驗，可以參考：
http://code.google.com/p/ncache/
5、nginx新開發的proxy_cache功能
從nginx-0.7.44版開始，nginx支持了類似squid較為正規的cache功能，目前還處於開發階段，支持相當有限，這個緩存是把鏈接用md5編碼hash後保存，所以它可以支持任意鏈接，同時也支持404/301/302這樣的非200狀態。
配置：
首先配置一個cache空間：
復制代碼 代碼如下:
proxy_cache_path /path/to/cache levels=1:2 keys_zone=NAME:10m inactive=5m max_size=2m clean_time=1m;
注意這個配置是在server標簽外，levels指定該緩存空間有兩層hash目錄，第一層目錄是1個字母，第二層為2個字母，保存的文件名就會類
似/path/to/cache/c/29/；keys_zone為這個空間起個名
字，10m指空間大小為10MB；inactive的5m指緩存默認時長5分鍾；max_size的2m是指單個文件超過2m的就不緩
存；clean_time指定一分鍾清理一次緩存。
location / {
proxy_passhttp://www.jb51.net/;
proxy_cache NAME;#使用NAME這個keys_zone
proxy_cache_valid 200 302 1h;#200和302狀態碼保存1小時
proxy_cache_valid 301 1d;#301狀態碼保存一天
proxy_cache_valid any 1m;#其它的保存一分鍾
}
ps：支持cache的0.7.44到0.7.51這幾個版本的穩定性均有問題，訪問有些鏈接會出現錯誤，所以這幾個版本最好不要在生產環境中
使用。nginx-0.7下目前所知較為穩定的版本是0.7.39。穩定版0.6.36版也是近期更新，如果在配置里沒有使用到0.7的一些新標簽新功
能，也可以使用0.6.36版。
Nginx緩存的內存佔用問題的一般解決方法
1、前些日子某服務被刷，每分鍾達到上幾百萬請求；當時採用了nginx cache來解決的；但是因為某服務不能緩存太久，當時設置了5s，那麼帶來的問題就是產生大量小文件，而且很快就刪除了。
2、通過
free -m
會發現used是27G；但是通過top查看進程占的內存並沒有那麼多
那內存去哪了？
3、通過查閱資料會發現(cat /proc/meminfo)
Slab: 22464312 kB
SReclaimable: 16474128 kB （這些是內核保持的但是可以釋放的inode和dentry的緩存）
SUnreclaim: 5990184 kB
4、這些內存為什麼會不自動清理呢？
某機房機器系統版本：Linux 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux（正常，沒出現內存快到100%的情況）
某機房機器系統版本：Linux 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux （不釋放）
5、通過設置如下參數來設置內存閥值
sysctl -w vm.extra_free_kbytes=6436787
sysctl -w vm.vfs_cache_pressure=10000
Ⅲ 如何在Nginx伺服器中啟用Gzip壓縮
在nginx.conf文件中加入如下配置：
gzip on;
gzip_proxied any;
gzip_types text/plain text/xml text/css application/x-javascript;
gzip_vary on;
之後重啟nginx服務就可以了。
Ⅳ linux nginx緩存文件在哪個文件夾
假設你是用包管理工具安裝的nginx：
如果你是redhat系列的，安裝包是.rpm包，或者你用yum安裝的話，這樣查找:
rpm
-ql
nginx
如果是ubuntu，也是類似的方法，具體參數你可以查查
如果你是源碼安裝的nginx
那麼需要問問安裝的人了，或者到/etc/nginx目錄下翻一翻配置文件？
Ⅳ NGINX proxy 模塊如何如何緩存動態頁面內容如何讓緩存過期
這里用虛擬機配置了下：
nginx 配置文件內容：
主要是這一句：
proxy_cache_path /www/ levels=1:2 keys_zone=Z:10m inactive=1m max_size=30g;
這一句定義一個區域，名字是 Z ，在內存中的空間為10MB ，硬碟中的最大空間為 30G;
inactive=1m 是，1分鍾之後緩存失效 ，從新從源伺服器請求
這里糾正一下，inactive=1m 如果緩存1分鍾沒人訪問，nginx 會刪除掉這些緩存
/usr/local/nginx/conf/nginx.conf
#user nobody;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
#pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
#gzip on;
proxy_cache_path /www/ levels=1:2 keys_zone=Z:10m inactive=1m max_size=30g;
server {
listen 80;
server_name localhost;
#charset koi8-r;
#access_log logs/host.access.log main;
location / {
root /www/;
#expires max;
#proxy_store on;
#proxy_store_access user:rw group:rw all:rw;
#proxy_temp_path /www/;
proxy_cache Z;
proxy_cache_valid 200 1m;
#expires max;
include proxy.conf;
if ( !-e $request_filename) {
proxy_pass http://192.168.1.199:45815;
}
}
#這里設置當 訪問 /ajax/目錄下的內容時候，直接從源伺服器讀取，主要用於ajax 的訪問請求，要求實時的
location /ajax/ {
include proxy.conf;
if ( !-e $request_filename) {
proxy_pass http://192.168.1.199:45815;
}
}
#location ~.*\.(jpg|png|jpeg|gif)
#{
# expires max;
#}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
# proxy the PHP scripts to Apache listening on 127.0.0.1:80
#
#location ~ \.php$ {
# proxy_pass http://127.0.0.1;
#}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
#location ~ \.php$ {
# root html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
# include fastcgi_params;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
# listen 8000;
# listen somename:8080;
# server_name somename alias another.alias;
# location / {
# root html;
# index index.html index.htm;
# }
#}
# HTTPS server
#
#server {
# listen 443;
# server_name localhost;
# ssl on;
# ssl_certificate cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_timeout 5m;
# ssl_protocols SSLv2 SSLv3 TLSv1;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers on;
# location / {
# root html;
# index index.html index.htm;
# }
#}
}
/usr/local/nginx/conf/proxy.conf
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Accept-Encoding 'gzip';
client_max_body_size 100m;
client_body_buffer_size 256k;
proxy_connect_timeout 60;
proxy_send_timeout 60;
proxy_read_timeout 60;
proxy_buffer_size 512k;
proxy_buffers 8 512k;
proxy_busy_buffers_size 512k;
proxy_temp_file_write_size 512k;
一開始我就這樣配置，認為可以成功了，結果發現動態文件無法被緩存，而html 文件可以被緩存，後來就到很多地方去問，
心想會不會是因為 文件 的 頭信息或者Last-Modified
信息和 ETag 造成的，就去問，http://www.dewen.org/q/9769/nginx+%E5%A6%82%E4%BD%95%E7%BC%93%E5%AD%98%E5%8A%A8%E6%80%81%E9%A1%B5%E9%9D%A2%EF%BC%9F
發現果真如此，馬上修改源伺服器的動態文件，加入以下代碼：
<%@ Page Language="C#" %>
<%
string date = Request.Headers.Get("If-Modified-Since");
if (date != null)
{
Response.StatusCode = 304;
Response.StatusDescription = "from cache";
return;
}
DateTime expDate = new DateTime(2037, 12, 31, 23, 55, 55);
Response.Cache.SetCacheability(HttpCacheability.Public);
Response.Cache.SetExpires(expDate);
Response.Cache.SetMaxAge(expDate - DateTime.Now);
Response.Cache.SetLastModified(new DateTime(2000, 1, 1));
%>
<%=DateTime.Now.ToString()%>
然後發現就可以緩存動態文件了。至此，下一步我就可以用nginx 作為用戶訪問的 伺服器了
這里截一些圖：
Ⅵ nginx log_fromat 的 $gzip_ratio 為什麼是空的
$gzip_ratio，應該是壓縮比率的的一個變數吧。
查看一下nginx相關gzip的功能有沒有打開。
附錄：
----------------------------------------------------------------------
gzip(GNU-ZIP)是一種壓縮技術。經過gzip壓縮後頁面大小可以變為原來的30%甚至更小，這樣，用戶瀏覽頁面的時候速度會塊得多。gzip的壓縮頁面需要瀏覽器和伺服器雙方都支持，實際上就是伺服器端壓縮，傳到瀏覽器後瀏覽器解壓並解析。瀏覽器那裡不需要我們擔心，因為目前的巨大多數瀏覽器都支持解析gzip過的頁面。
Nginx的壓縮輸出有一組gzip壓縮指令來實現。相關指令位於http{….}兩個大括弧之間。
gzip on;
//該指令用於開啟或關閉gzip模塊(on/off)
gzip_min_length 1k;
//設置允許壓縮的頁面最小位元組數，頁面位元組數從header頭得content-length中進行獲取。默認值是0，不管頁面多大都壓縮。建議設置成大於1k的位元組數，小於1k可能會越壓越大。
gzip_buffers 4 16k;
//設置系統獲取幾個單位的緩存用於存儲gzip的壓縮結果數據流。4 16k代表以16k為單位，安裝原始數據大小以16k為單位的4倍申請內存。
gzip_http_version 1.1;
//識別http的協議版本(1.0/1.1)
gzip_comp_level 2;
//gzip壓縮比，1壓縮比最小處理速度最快，9壓縮比最大但處理速度最慢(傳輸快但比較消耗cpu)
gzip_types text/plain application/x-javascript text/css application/xml
//匹配mime類型進行壓縮，無論是否指定,」text/html」類型總是會被壓縮的。
gzip_vary on;
//和http頭有關系，加個vary頭，給代理伺服器用的，有的瀏覽器支持壓縮，有的不支持，所以避免浪費不支持的也壓縮，所以根據客戶端的HTTP頭來判斷，是否需要壓縮
nginx 配置gzip段如下：
gzip on;
gzip_min_length 1k;
gzip_buffers 16 64k;
gzip_http_version 1.1;
gzip_comp_level 6;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
Ⅶ nginx gzip 壓縮比 多少好
隨著壓縮率的提高，所消耗的CPU也會越來越多，建議值是4，但是DavidYin的建議是直接用5。因為每提高一級壓縮，數據就減少大約2到3KB，而從5到6，只有減少大約0.5KB，再之後也幾乎沒有什麼變化了。所以就直接設置 gzip_comp_level 5
對於CPU的消耗，我覺得還是不是那麼的厲害，畢竟靜態文件，還可以設置過期頭，讓它的有效緩存期長一點，比如設置成半年一年的。實際上CPU的壓力在這上面是沒有那麼大的。
Ⅷ nginx 時間 長 怎麼優化 gzip
user和pid應該按默認設置 - 我們不會更改這些內容，因為更改與否沒有什麼不同。
worker_processes 定義了nginx對外提供web服務時的worker進程數。最優值取決於許多因素，包括（但不限於）CPU核的數量、存儲數據的硬碟數量及負載模式。不能確定的時候，將其設置為可用的CPU內核數將是一個好的開始（設置為「auto」將嘗試自動檢測它）。
worker_rlimit_nofile 更改worker進程的最大打開文件數限制。如果沒設置的話，這個值為操作系統的限制。設置後你的操作系統和Nginx可以處理比「ulimit -a」更多的文件，所以把這個值設高，這樣nginx就不會有「too many open files」問題了。
Events模塊
events模塊中包含nginx中所有處理連接的設置。
Ⅸ nginx gzip哪個階段做壓縮
隨著nginx的發展，越來越多的網站使用nginx，因此nginx的優化變得越來越重要，今天我們來看看nginx的gzip壓縮到底是怎麼壓縮的呢？
gzip(GNU-ZIP)是一種壓縮技術。經過gzip壓縮後頁面大小可以變為原來的30%甚至更小，這樣，用戶瀏覽頁面的時候速度會塊得多。gzip的壓縮頁面需要瀏覽器和伺服器雙方都支持，實際上就是伺服器端壓縮，傳到瀏覽器後瀏覽器解壓並解析。瀏覽器那裡不需要我們擔心，因為目前的巨大多數瀏覽器都支持解析gzip過的頁面。
Nginx的壓縮輸出有一組gzip壓縮指令來實現。相關指令位於http{….}兩個大括弧之間。
默認情況下，Nginx的gzip壓縮是關閉的， gzip壓縮功能就是可以讓你節省不少帶寬，但是會增加伺服器CPU的開銷哦（與節約帶寬相比，寧願選擇節約帶寬，節約帶寬就是快速響應用戶的訪問），如下圖，
Nginx默認只對text/html進行壓縮 ，如果要對html之外的內容進行壓縮傳輸，我們需要手動來調。 開啟gzip的指令如下：
[plain] view plain
gzip on;
gzip_min_length 1k;
gzip_buffers 16 64k;
gzip_http_version 1.1;
gzip_comp_level 6;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;
gzip on;
//該指令用於開啟或關閉gzip模塊(on/off)
Ⅹ nginx緩存性能怎麼樣
Nginx緩存對於不少人來說都不是很明朗的一個知識。那麼好我們就借介紹有關優點和缺點的機會把大家帶進Nginx緩存的世界。希望大家在文中能找到自己相關的使用方法。
兩種Nginx緩存都有著基本一樣的優點和缺點：
缺點1：不支持帶參數的動態鏈接，比如read.php?id=1，因為Nginx緩存只保存文件名，所以這個鏈接只在文件系統下保存為read.php，這樣用戶訪問read.php?id=2時會返回不正確的結果。同時不支持http://www.sudone.com/這種形式的首頁和二級目錄http://www.sudone.com/download/，因為Nginx緩存非常老實，會將這樣的請求照鏈接寫入文件系統，而這個鏈接顯然是一個目錄，所以保存失敗。這些情況都需要寫rewrite才能正確保存。
缺點2：Nginx緩存內部沒有緩存過期和清理的任何機制，這些緩存的文件會永久性地保存在機器上，如果要緩存的東西非常多，那就會撐暴整個硬碟空間。為此可以使用一個shell腳本定期清理，同時可以撰寫php等動態程序來做實時更新。
缺點3：只能緩存200狀態碼，因此後端返回301/302/404等狀態碼都不會緩存，假如恰好有一個訪問量很大的偽靜態鏈接被刪除，那就會不停穿透導致後端承載不小壓力。
缺點4：Nginx不會自動選擇內存或硬碟作為存儲介質，一切由配置決定，當然在當前的操作系統里都會有操作系統級的文件緩存機制，所以存在硬碟上也不需要過分擔心大並發讀取造成的io性能問題。
Nginx傳統緩存的缺點也是它和squid等緩存軟體的不同之特色，所以也可看作其優點。在生產應用中它常常用作和squid的搭檔，squid對於帶?的鏈接往往無法阻擋，而Nginx能將其訪問攔住，例如：http://sudone.com/?和http://sudone.com/在squid上會被當做兩個鏈接，所以會造成兩次穿透；而Nginx只會保存一次，無論鏈接變成http://sudone.com/?1還是http://sudone.com/?123，均不能透過Nginx緩存，從而有效地保護了後端主機。
Nginx緩存會非常老實地將鏈接形式保存到文件系統中，這樣對於一個鏈接，可以很方便地查閱它在緩存機器上的緩存狀態和內容，也可以很方便地和別的文件管理器如rsync等配合使用，它完完全全就是一個文件系統結構。
這兩種傳統緩存都可以在linux下將文件保存到/dev/shm里，一般我也是這么做的，這樣可以利用系統內存來做緩存，利用內存的話，清理過期內容速度就會快得多。使用/dev/shm/時除了要把tmp目錄也指向到/dev/shm這個分區外，如果有大量小文件和目錄，還要修改一下這個內存分區的inode數量和最大容量：
mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm
上面的命令在一台有3G內存的機器上使用，因為/dev/shm默認最大內存是系統內存的一半就是1500M，這條命令將其調大成2500M，同時shm系統inode數量默認情況下可能是不夠用的，但有趣的是它可以隨意調節，這里調節為480000保守了點，但也基本夠用了。