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。

./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 的配置如下：

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;

}

为了使操作系统不成为瓶颈，调整了一下参数，如下：

[[email protected] 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如下：

[[email protected] 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

[[email protected] 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。