nginx折騰記（HTTP性能能測試，與Apache對比）

來自：http://www.cnblogs.com/killkill/archive/2010/04/14/1711810.html

話說nginx在大壓力的環境中比apache的表現要好，於是下載了一個來折騰一下。

下載並編譯安裝，我的編譯過程有點特別：

1。去除調試信息，修改$nginx_setup_path/auto/cc/gcc這個文件，將 CFLAGS="$CFLAGS -g"  這一行註釋掉。

2。由於僅測試WEB服務器的性能，所以不安裝FastCGI。

1 2 3 4 5 6 7

./configure \   --prefix=/opt/nginx \   --user=www \   --group=www \   --with-http_stub_status_module \   --with-http_ssl_module \   --without-http_fastcgi_module

安裝完成之後，將一堆生產環境中靜態化了的HTML頁面copy 到 nginx 的服務器上，我的 nginx.conf 的配置如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

worker_processes  8; worker_rlimit_nofile 102400; events {     use epoll;     worker_connections  204800; } http {     include       mime.types;     default_type  application/octet-stream;     sendfile        on;     tcp_nopush     on;     charset GBK ;     keepalive_timeout  60;     server_names_hash_bucket_size 128;     client_header_buffer_size 2k;     large_client_header_buffers 4 4k;     client_max_body_size 8m;     open_file_cache max=102400 inactive=20s;     server     {         listen       80;                           location /         {           root   /tmp/webapps/;           index  index.html index.htm;         }                   location = /NginxStatus         {           stub_status on;           access_log off;         }                   error_page   500 502 503 504  /50x.html;                   location = /50x.html         {             root   html;         }     } }

爲了使操作系統不成爲瓶頸，調整了一下參數，如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

[root@logserver etc]# cat sysctl.conf | grep -v "^$" | grep -v "^#"; net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 0 kernel.core_uses_pid = 1 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128 fs.file-max = 6553600 net.ipv4.tcp_syncookies = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 kernel.shmmax = 68719476736 kernel.shmall = 4294967296 net.ipv4.tcp_max_tw_buckets = 6000 net.ipv4.tcp_sack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_wmem = 4096 16384 4194304 net.core.wmem_default = 8388608 net.core.rmem_default = 8388608 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.core.netdev_max_backlog = 262144 net.core.somaxconn = 262144 net.ipv4.tcp_max_orphans = 3276800 net.ipv4.tcp_max_syn_backlog = 262144 net.ipv4.tcp_timestamps = 0 net.ipv4.tcp_synack_retries = 1 net.ipv4.tcp_syn_retries = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_mem = 94500000 915000000 927000000 net.ipv4.tcp_fin_timeout = 1 net.ipv4.tcp_keepalive_time = 30 net.ipv4.ip_local_port_range = 1024 65000

我這臺是比較老的服務器了，DELL 2850 兩顆 Intel(R) Xeon(TM) CPU 2.80GHz，OS認作4個CPU，4GB內存，OS如下：

1 2 3 4

[root@logserver etc]# uname -a Linux logserver 2.6.9-78.ELsmp #1 SMP Thu Jul 24 23:54:48 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux [root@logserver etc]# cat /etc/redhat-release CentOS release 4.7 (Final)

測試工具是 apache 的 ab ，用來模擬，大量的併發連接，本來是在另一臺虛擬機中模擬客戶端，但隨着壓力的上升，還沒壓死 nginx 就先將自己壓死了 -_- ，最後只能自己壓自己了。

測試腳本大概如下：

1	ab -n 100000 -c >client_number< [-k] http://***********/cms/index.html

index.html 的大小是：123784 byte

我將測試數據整理到Excel中，猛擊這裏下載，如下：

nginx 短連接測試結果（1/20抽樣展示）

nginx 長連接測試結果（1/20抽樣展示）

單看數字可能比較枯燥，還是看圖吧：

 

針對第一組圖片，有幾個地方需要解析一下的。

“Concurrency Level”並不對應有多少個瀏覽器或者多少個用戶，應該理解爲併發連接數，通常IE訪問一個網頁，打開3~10個連接，正常情況下，10000個“客戶端數”可以非常粗略地認爲1000~3000個用戶吧。

長連接的典型代表是 HTTP 1.1 ，而短連接的典型代表是 HTTP 1.0，支持HTTP 1.1的瀏覽器早就遍地都是了，爲什麼還要測試短連接呢？第一，這是因爲實際的瀏覽中，一個“長”連接不可能像ab測試中的“長”連接這麼長，所以短鏈接的測試成績作爲一個“底線”；第二，某些掃描工具用的就是短鏈接的方式，既然要做互聯網的應用，也要“照顧”它們啊。因此，在生產環境中，真實的成績會在紅線和藍線之間的區間，具體是怎麼樣呢，“這個就不能說太細了”。

關於“傳輸率”這幅圖的縱座標的意義，100000 相當於 100MB/sec，也就是常說的百兆網絡（忽略 CSMA/CD 造成的損失），而常說的千兆網絡，經過測試，大概在400000~500000之間，換句話來說，如果nginx服務器的出口帶寬是百兆網絡的話，瓶頸在網絡而不是nginx。

 

   

針對第二組圖片也是有幾個地方需要解析一下的：

生產環境的成績應該是在藍線和紅線之間的區間，這個就不用再解析了吧。

“Logest Response Time” 實際上取的是能完成所有請求中的99%時的時間，這樣可以屏蔽一些誤差。

隨着壓力的增加，響應時間的飆升是可以預見的，但是多少纔算是一個可接受範圍呢？在2009系統架構師大會騰訊的邱躍鵬在《海量SNS網站的柔性運營》中的發言提到的“用戶速度體驗的1-3-10原則”：

可以簡單的認爲：如果以3秒的響應時間作爲標準的話，nginx能應付不超過10000的併發連接數，如果以10秒響應時間作爲標準的話，nginx能應付15000以下個併發連接，當然，可能場合不同，您的用戶連0.3秒都無法忍受，這個就要另說咯。

如果我假設，只要服務器不出現“連接重置”，“服務器無響應”等錯誤，只要能返回內容，我就願意等，那麼nginx能應付多大的併發連接數呢？我自己做了個測試，20000+20000個長連接，20000個短鏈接，同時壓向nginx，結果如何呢？

nginx還是頂住了，沒掛。我曾試過再加大壓力，但是始終跑不完測試，結果作罷。

 

不怕不識貨,就怕貨比貨，大名鼎鼎的apache又會怎麼樣呢？在此之前大家可以看看這篇帖子——大家猜這樣的linux服務器 apache最大的併發數是多少，帖子中提到的服務器比我這臺還要好，但是，超過70%的人都認爲突破不了3000大關，咱們“不看廣告，看療效”。

我的Apache使用worker模式，配置如下：

1 2 3 4 5 6 7 8 9 10

<ifmodule worker.c>     ServerLimit  1000     ThreadLimit  11000     StartServers 40     MaxClients   30000     MinSpareThreads  1000     MaxSpareThreads  1000     ThreadsPerChild  300     MaxRequestsPerChild 0 </ifmodule>

Apache 短連接成績（1/10抽樣展示）

Apache 短連接成績（1/10抽樣展示）

Apache 的結果圖形和nginx類似，但是大家請留意橫座標，最大是10000，而nginx最大的是20000，這是由於測到10000的時候，再往上加壓力Apache就受不了，不是SWAP用盡就是連接超時。

 

我把nginx和Apache的圖標拼在一起，方便對比：

 

從圖表可以看到nginx作單純的WEB服務器，也就是放靜態內容，性能上比Apache要好，特別可承受壓力、帶寬及資源消耗上都要優於Apache。很多大型網站都喜歡把nginx放在前端，可能就是這個原因吧。