nginx折腾记(HTTP性能能测试,与Apache对比)
2010-06-16 22:19
666 查看
本文转自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。
安装完成之后,将一堆生产环境中静态化了的HTML页面copy 到 nginx 的服务器上,我的 nginx.conf 的配置如下:
为了使操作系统不成为瓶颈,调整了一下参数,如下:
我这台是比较老的服务器了,DELL 2850 两颗 Intel(R) Xeon(TM) CPU 2.80GHz,OS认作4个CPU,4GB内存,OS如下:
测试工具是 apache 的 ab ,用来模拟,大量的并发连接,本来是在另一台虚拟机中模拟客户端,但随着压力的上升,还没压死 nginx 就先将自己压死了 -_- ,最后只能自己压自己了。
测试脚本大概如下:
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模式,配置如下:
view source
print?
Apache 短连接成绩(1/10抽样展示)
Apache 短连接成绩(1/10抽样展示)
Apache 的结果图形和nginx类似,但是大家请留意横坐标,最大是10000,而nginx最大的是20000,这是由于测到10000的时候,再往上加压力Apache就受不了,不是SWAP用尽就是连接超时。
我把nginx和Apache的图标拼在一起,方便对比:
从图表可以看到nginx作单纯的WEB服务器,也就是放静态内容,性能上比Apache要好,特别可承受压力、带宽及资源消耗上都要优于Apache。很多大型网站都喜欢把nginx放在前端,可能就是这个原因吧。
话说nginx在大压力的环境中比apache的表现要好,于是下载了一个来折腾一下。
下载并编译安装,我的编译过程有点特别:
1。去除调试信息,修改$nginx_setup_path/auto/cc/gcc这个文件,将 CFLAGS="$CFLAGS -g"这一行注释掉。
2。由于仅测试WEB服务器的性能,所以不安装FastCGI。
1 | ./configure / |
2 | --prefix=/opt/nginx / |
3 | --user=www / |
4 | --group=www / |
5 | --with-http_stub_status_module / |
6 | --with-http_ssl_module / |
7 | --without-http_fastcgi_module |
01 | worker_processes8; |
02 | worker_rlimit_nofile 102400; |
03 | events |
04 | { |
05 | use epoll; |
06 | worker_connections204800; |
07 | } |
08 | http |
09 | { |
10 | include mime.types; |
11 | default_typeapplication/octet-stream; |
12 | sendfileon; |
13 | tcp_nopush on; |
14 | charset GBK ; |
15 | keepalive_timeout60; |
16 | server_names_hash_bucket_size 128; |
17 | client_header_buffer_size 2k; |
18 | large_client_header_buffers 4 4k; |
19 | client_max_body_size 8m; |
20 | open_file_cache max=102400 inactive=20s; |
21 | server |
22 | { |
23 | listen 80; |
24 |
25 | location / |
26 | { |
27 | root /tmp/webapps/; |
28 | indexindex.html index.htm; |
29 | } |
30 |
31 | location = /NginxStatus |
32 | { |
33 | stub_status on; |
34 | access_log off; |
35 | } |
36 |
37 | error_page 500 502 503 504/50x.html; |
38 |
39 | location = /50x.html |
40 | { |
41 | root html; |
42 | } |
43 | } |
44 | } |
01 | [root@logserver etc]# cat sysctl.conf | grep -v "^$" | grep -v "^#"; |
02 | net.ipv4.ip_forward = 0 |
03 | net.ipv4.conf.default.rp_filter = 1 |
04 | net.ipv4.conf.default.accept_source_route = 0 |
05 | kernel.sysrq = 0 |
06 | kernel.core_uses_pid = 1 |
07 | kernel.shmmni = 4096 |
08 | kernel.sem = 250 32000 100 128 |
09 | fs.file-max = 6553600 |
10 | net.ipv4.tcp_syncookies = 1 |
11 | kernel.msgmnb = 65536 |
12 | kernel.msgmax = 65536 |
13 | kernel.shmmax = 68719476736 |
14 | kernel.shmall = 4294967296 |
15 | net.ipv4.tcp_max_tw_buckets = 6000 |
16 | net.ipv4.tcp_sack = 1 |
17 | net.ipv4.tcp_window_scaling = 1 |
18 | net.ipv4.tcp_rmem = 4096 87380 4194304 |
19 | net.ipv4.tcp_wmem = 4096 16384 4194304 |
20 | net.core.wmem_default = 8388608 |
21 | net.core.rmem_default = 8388608 |
22 | net.core.rmem_max = 16777216 |
23 | net.core.wmem_max = 16777216 |
24 | net.core.netdev_max_backlog = 262144 |
25 | net.core.somaxconn = 262144 |
26 | net.ipv4.tcp_max_orphans = 3276800 |
27 | net.ipv4.tcp_max_syn_backlog = 262144 |
28 | net.ipv4.tcp_timestamps = 0 |
29 | net.ipv4.tcp_synack_retries = 1 |
30 | net.ipv4.tcp_syn_retries = 1 |
31 | net.ipv4.tcp_tw_recycle = 1 |
32 | net.ipv4.tcp_tw_reuse = 1 |
33 | net.ipv4.tcp_mem = 94500000 915000000 927000000 |
34 | net.ipv4.tcp_fin_timeout = 1 |
35 | net.ipv4.tcp_keepalive_time = 30 |
36 | net.ipv4.ip_local_port_range = 1024 65000 |
1 | [root@logserver etc]# uname -a |
2 | 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 |
3 | [root@logserver etc]# cat /etc/redhat-release |
4 | CentOS release 4.7 (Final) |
测试脚本大概如下:
1 | ab -n 100000 -c <client_number> [-k] http://***********/cms/index.html </client_number> |
我将测试数据整理到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模式,配置如下:
view source
print?
01 | <ifmodule worker.c> |
02 | ServerLimit1000 |
03 | ThreadLimit11000 |
04 | StartServers 40 |
05 | MaxClients 30000 |
06 | MinSpareThreads1000 |
07 | MaxSpareThreads1000 |
08 | ThreadsPerChild300 |
09 | MaxRequestsPerChild 0 |
10 | </ifmodule> |
Apache 短连接成绩(1/10抽样展示)
Apache 短连接成绩(1/10抽样展示)
Apache 的结果图形和nginx类似,但是大家请留意横坐标,最大是10000,而nginx最大的是20000,这是由于测到10000的时候,再往上加压力Apache就受不了,不是SWAP用尽就是连接超时。
我把nginx和Apache的图标拼在一起,方便对比:
从图表可以看到nginx作单纯的WEB服务器,也就是放静态内容,性能上比Apache要好,特别可承受压力、带宽及资源消耗上都要优于Apache。很多大型网站都喜欢把nginx放在前端,可能就是这个原因吧。
相关文章推荐
- [原]nginx折腾记(HTTP性能能测试,与Apache对比)
- nginx折腾记(HTTP性能能测试,与Apache对比)
- [原]nginx折腾记(HTTP性能能测试,与Apache对比)
- nginx折腾记(HTTP性能能测试,与Apache对比)
- nginx折腾记(HTTP性能能测试,与Apache对比)
- nginx折腾记(HTTP性能能测试,与Apache对比)
- nginx折腾记(HTTP性能能测试,与Apache对比)
- nginx折腾记(HTTP性能能测试,与Apache对比)
- nginx折腾记(HTTP性能能测试,与Apache对比)
- [转]nginx折腾记(HTTP性能能测试,与Apache对比)
- apache nginx 性能简单对比测试
- nginx和apache并发性能测试对比
- nginx折腾记(HTTP性能能测试,与Apache对比)
- 利用http_load测试Web引擎性能(有phalcon和thinkphp对比)
- Nginx性能测试工具之http_load
- Apache、Nginx、Mongoose 静态页面性能对比
- nginx与apache详细性能对比
- Nginx-4:与apache性能对比
- golang与node.js的http模块性能对比测试(go1)
- 小测试apache与nginx请求速度的对比