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

楊航收集技術資料，分享給大家



總結

以上是生活随笔為你收集整理的nginx比较apache的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。