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放在前端，可能就是这个缘由吧。