nginx比較apache

http://blog.csdn.net/hanghangaidoudou/article/details/8506963

話說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放在前端，可能就是這個緣由吧。