51Testing软件测试论坛

标题: [转]nginx折腾记（HTTP性能能测试，与Apache对比） [打印本页]
作者: lsekfe    时间: 2016-10-19 16:37
标题: [转]nginx折腾记（HTTP性能能测试，与Apache对比）
话说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
复制代码
安装完成之后，将一堆生产环境中静态化了的HTML页面copy 到 nginx 的服务器上，我的 nginx.conf 的配置如下：
  1. worker_processes  8;
  2. worker_rlimit_nofile 102400;
  3. events
  4. {
  5.     use epoll;
  6.     worker_connections  204800;
  7. }
  8. http
  9. {
  10.     include       mime.types;
  11.     default_type  application/octet-stream;
  12.     sendfile        on;
  13.     tcp_nopush     on;
  14.     charset GBK ;
  15.     keepalive_timeout  60;
  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.           index  index.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. }
复制代码
为了使操作系统不成为瓶颈，调整了一下参数，如下：
  1. [root@logserver etc]# cat sysctl.conf | grep -v "^[        DISCUZ_CODE_2        ]quot; | grep -v "^#";
  2. net.ipv4.ip_forward = 0
  3. net.ipv4.conf.default.rp_filter = 1
  4. net.ipv4.conf.default.accept_source_route = 0
  5. kernel.sysrq = 0
  6. kernel.core_uses_pid = 1
  7. kernel.shmmni = 4096
  8. kernel.sem = 250 32000 100 128
  9. 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
复制代码
我这台是比较老的服务器了，DELL 2850 两颗 Intel(R) Xeon(TM) CPU 2.80GHz，OS认作4个CPU，4GB内存，OS如下：
  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)
复制代码
测试工具是 apache 的 ab ，用来模拟，大量的并发连接，本来是在另一台虚拟机中模拟客户端，但随着压力的上升，还没压死 nginx 就先将自己压死了 -_- ，最后只能自己压自己了。
测试脚本大概如下：
  1.         
  2. ab -n 100000 -c >client_number< [-k] http://***********/cms/index.html
复制代码
index.html 的大小是：123784 byte
我将测试数据整理到Excel中，猛击这里下载，如下：
[attach]103096[/attach]
nginx 短连接测试结果（1/20抽样展示）
[attach]103097[/attach]
nginx 长连接测试结果（1/20抽样展示）
单看数字可能比较枯燥，还是看图吧：

[attach]103098[/attach]
[attach]103099[/attach]
针对第一组图片，有几个地方需要解析一下的。
“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。
[attach]103100[/attach]
[attach]103104[/attach]
针对第二组图片也是有几个地方需要解析一下的：
生产环境的成绩应该是在蓝线和红线之间的区间，这个就不用再解析了吧。
“Logest Response Time” 实际上取的是能完成所有请求中的99%时的时间，这样可以屏蔽一些误差。
随着压力的增加，响应时间的飙升是可以预见的，但是多少才算是一个可接受范围呢？在2009系统架构师大会腾讯的邱跃鹏在《海量SNS网站的柔性运营》中的发言提到的“用户速度体验的1-3-10原则”：
[attach]103101[/attach]
可以简单的认为：如果以3秒的响应时间作为标准的话，nginx能应付不超过10000的并发连接数，如果以10秒响应时间作为标准的话，nginx能应付15000以下个并发连接，当然，可能场合不同，您的用户连0.3秒都无法忍受，这个就要另说咯。
如果我假设，只要服务器不出现“连接重置”，“服务器无响应”等错误，只要能返回内容，我就愿意等，那么nginx能应付多大的并发连接数呢？我自己做了个测试，20000+20000个长连接，20000个短链接，同时压向nginx，结果如何呢？
[attach]103102[/attach]
[attach]103103[/attach]
nginx还是顶住了，没挂。我曾试过再加大压力，但是始终跑不完测试，结果作罢。

不怕不识货,就怕货比货，大名鼎鼎的apache又会怎么样呢？在此之前大家可以看看这篇帖子——大家猜这样的linux服务器 apache最大的并发数是多少，帖子中提到的服务器比我这台还要好，但是，超过70%的人都认为突破不了3000大关，咱们“不看广告，看疗效”。
我的Apache使用worker模式，配置如下：
  1. <ifmodule worker.c>
  2.     ServerLimit  1000
  3.     ThreadLimit  11000
  4.     StartServers 40
  5.     MaxClients   30000
  6.     MinSpareThreads  1000
  7.     MaxSpareThreads  1000
  8.     ThreadsPerChild  300
  9.     MaxRequestsPerChild 0
  10. </ifmodule>
复制代码
[attach]103105[/attach]

Apache 短连接成绩（1/10抽样展示）
[attach]103106[/attach]
Apache 短连接成绩（1/10抽样展示）
[attach]103107[/attach]
[attach]103108[/attach]
[attach]103109[/attach]
[attach]103110[/attach]

Apache 的结果图形和nginx类似，但是大家请留意横坐标，最大是10000，而nginx最大的是20000，这是由于测到10000的时候，再往上加压力Apache就受不了，不是SWAP用尽就是连接超时。

我把nginx和Apache的图标拼在一起，方便对比：
[attach]103111[/attach]
[attach]103112[/attach]
[attach]103113[/attach]
[attach]103114[/attach]
从图表可以看到nginx作单纯的WEB服务器，也就是放静态内容，性能上比Apache要好，特别可承受压力、带宽及资源消耗上都要优于Apache。很多大型网站都喜欢把nginx放在前端，可能就是这个原因吧。

作者: 神仙也考试    时间: 2016-10-19 16:58
nginx作为俄罗斯的web容器，个人也在学习中
作者: gutifeng    时间: 2020-6-27 18:05
学习了
作者: Miss_love    时间: 2020-12-25 14:47
学习了



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2