Nginx调优总结-第六部分编译优化与简单测试

nginx,总结,第六,部分,编译,优化,简单,测试 · 浏览次数 : 133

小编点评

1. 使用--net=host 应该比使用单纯的 -p docker0 网络要好很多。 2. 进行编译优化的二进制应该比不编译优化的二进制要好一些。但是不是特别明显。 3. 增加了过多的模块可能对性能有影响. 最简化的编译应该是性能最好的。 4. 基于3的结论,重新编译一个最小化编译的包进行再次验证.发现包含的模块越少,性能越好。 5. 多次进行ab 的压测与验证, 结论基本上符合这个规律。 6. 平均数较难取得.本次仅使用一个worker 进行测试验证. 机器配置较高. 7. 开启了keepalive 性能会有一定的提升.所以无论nginx作为客户端还是服务器端建议开启keepalive。 8. 归纳总结以上内容,生成内容时需要带简单的排版

正文

第六部分 编译优化

Nginx可以自行编译,所以里面可以设置多个编译策略. 
也可以自行修改源码,便于比如进行ip_hash的全IP地址验证.
也可以修改nginx的版本号等信息, 避免内发现. 

还可以按照不同的CPU类型进行优化
选择更高级别的优化参数.
不编译debug等的信息,便于降低内存占用等. 

修改源码-1

ip_hash 时修改为全部IPV4地址段进行取hash处理

src/http/modules/ngx_http_upstream_ip_hash_module.c

把里面的3修改成4 就可以进行全IP地址段的hash运算. 

    case AF_INET:
        sin = (struct sockaddr_in *) r->connection->sockaddr;
        iphp->addr = (u_char *) &sin->sin_addr.s_addr;
        iphp->addrlen = 3; # 修改成4 
        break;
    default:
        iphp->addr = ngx_http_upstream_ip_hash_pseudo_addr;
        iphp->addrlen = 3; # 修改成4
    }

    for ( ;; ) {

        for (i = 0; i < (ngx_uint_t) iphp->addrlen; i++) {
            hash = (hash * 113 + iphp->addr[i]) % 6271;
        }

修改源码-2

修改nginx的版本号
需要修改多个文件:
注意 我把 nginx修改成我我的ID. 

vim src/core/nginx.h
#define NGINX_VERSION      "1127"
#define NGINX_VER          "JNXLH/" NGINX_VERSION
#define NGINX_VAR          "JNXLH"

vim src/http/ngx_http_header_filter_module.c
static u_char ngx_http_server_string[] = "Server: JNXLH" CRLF;
static u_char ngx_http_server_full_string[] = "Server: " NGINX_VER CRLF;
static u_char ngx_http_server_build_string[] = "Server: " NGINX_VER_BUILD CRLF;

修改源码-3

去除 debug信息

vim auto/cc/gcc
# debug
CFLAGS=”$CFLAGS -g”
可以将 CFLAGS进行注释就可以. 

注意 取消了debug之后文件会出现极大的缩小. 

我用下面的编译脚本编译完后文件由8.3M 减小到了4.4M大小. 

编译打包命令

./configure --prefix=/opt/nginx \
--sbin-path=/opt/nginx/nginx \
--conf-path=/opt/nginx/nginx.conf \
--pid-path=/opt/nginx/nginx.pid \
--with-http_ssl_module \
--with-pcre=../pcre2-10.42 \
--with-zlib=../zlib-1.2.13 \
--with-openssl=../openssl-1.1.1s \
--with-stream \
--with-stream_ssl_preread_module \
--with-cc-opt='-O3' \
--with-cpu-opt=core 

编译打包命令解析

--with-pcre=../pcre2-10.42 \
--with-zlib=../zlib-1.2.13 \
--with-openssl=../openssl-1.1.1s \
这三个是使用了很新的组建, 有正则表达式, 压缩 和openssl加解密.

--with-http_ssl_module \
增加https的支持.

--with-stream \
--with-stream_ssl_preread_module \
增加四层负载的功能. 
增加四层负载然后可以进行转发https的功能. 

--with-cc-opt='-O3' \
编译优化参数开到最高, 编译时间变长,但是编译后的性能最好. 

--with-cpu-opt=core 
官方说明里面可以写pentium等.但是据说如果是服务器可以写core
所以进行验证了. 

config的结果信息

Configuration summary
  + using PCRE2 library: ../pcre2-10.42
  + using OpenSSL library: ../openssl-1.1.1s
  + using zlib library: ../zlib-1.2.13

  nginx path prefix: "/opt/nginx"
  nginx binary file: "/opt/nginx/nginx"
  nginx modules path: "/opt/nginx/modules"
  nginx configuration prefix: "/opt/nginx"
  nginx configuration file: "/opt/nginx/nginx.conf"
  nginx pid file: "/opt/nginx/nginx.pid"
  nginx error log file: "/opt/nginx/logs/error.log"
  nginx http access log file: "/opt/nginx/logs/access.log"
  nginx http client request body temporary files: "client_body_temp"
  nginx http proxy temporary files: "proxy_temp"
  nginx http fastcgi temporary files: "fastcgi_temp"
  nginx http uwsgi temporary files: "uwsgi_temp"
  nginx http scgi temporary files: "scgi_temp"

编译成功后处理响应文件

进入编译后的文件目录
cd /opt/nginx
执行命令
sed -i 's/nginx/JNXLH/g' html/index.html
就会修改 访问界面, 没有nginx的字样了. 

然后F12看到的服务器信息为:
Server: JNXLH/1127

使用ab进行验证

安装ab非常简单:
yum -y install httpd-tools

最简单的测试可以使用两个参数进行:
-n	即requests,用于指定压力测试总共的执行次数。
-c	即concurrency,用于指定的并发数。

简单的ab测试结果

优化后的测试结果:
ab -c 10000 -n 50000 http://10.110.80.116:81/

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  244  65.2    242    1287
Processing:    71  258  85.4    253     504
Waiting:        0   32  99.2      0     381
Total:        385  503  55.8    496    1502

优化编译前的测试结果:
ab -c 10000 -n 50000 http://10.110.80.116:82/

              min  mean[+/-sd] median   max
Connect:        0  258  84.9    252    1388
Processing:    76  271  95.5    264     541
Waiting:        0   34 105.8      0     444
Total:        426  529  74.8    506    1509

基于容器运行的测试结果

docker run --name nginx83 -d -p 83:83 -v /opt/nginx/nginx83.conf:/etc/nginx/nginx.conf nginx
使用docker0 方式 原生 nginx 无调优的容器.
挂载模式的nginx的配置文件唯一不同的是使用83端口. 
ab -c 10000 -n 50000 http://10.110.80.116:83/
              min  mean[+/-sd] median   max
Connect:        0  344 158.6    325    1344
Processing:    48  326 109.4    326     664
Waiting:        0   28 105.5      0     470
Total:        429  671 175.9    633    1829

docker run --name nginx84 -d --net=host -v /opt/nginx/nginx84.conf:/etc/nginx/nginx.conf nginx
这个命令使用 宿主机的网络进行暴露服务. 
端口使用 84的端口. 
ab -c 10000 -n 50000 http://10.110.80.116:84/
              min  mean[+/-sd] median   max
Connect:        0  254  55.7    254     363
Processing:    53  266  88.9    263     515
Waiting:        0   33 102.2      0     373
Total:        346  520  46.6    516     678

最小化编译的二进制的性能测试结果

编译配置文件为:
./configure --prefix=/opt/nginx85 \
--sbin-path=/opt/nginx85/nginx \
--conf-path=/opt/nginx85/nginx.conf \
--pid-path=/opt/nginx85/nginx.pid \
--with-cc-opt='-O3' \
--with-cpu-opt=core 

注意这样编译打包的文件 仅有 900k 左右. 比之前的4.4M又有了较大的缩减. 
ab -c 10000 -n 50000 http://10.110.80.116:85/
              min  mean[+/-sd] median   max
Connect:        0  242  68.6    240    1292
Processing:    53  254  86.9    250     502
Waiting:        0   31  97.9      0     356
Total:        336  496  62.6    493    1507

扩充测试

工作线程和内核绑定都是AUTO时
4路18核心 144线程的测试结果:
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0  434 165.6    403    1359
Processing:    44  487 143.3    487     761
Waiting:        0  142  91.3    134     749
Total:        594  922 137.8    941    1921
是所有的测试结果里面最差的. 

改成 8个工作进程.加auto绑定核心
              min  mean[+/-sd] median   max
Connect:        0  381 170.0    350    1549
Processing:    63  408 112.4    410     616
Waiting:        0  157  98.7    141     589
Total:        506  788 158.1    818    1842

也比较差. 但是比AUTO要好
说明在简单处理情况下单线程最好. 
但是稍微复杂一点 包含反向代理的还是需要多几个worker进程才可以.

增加 -k 参数

具体结果不再写了. 
但是发现增加了 keepalive
多核心的平均时间到了200ms 有了巨大的提升. 
并且在不通配置上面都有了一些提升. 
单线程优化过的编译包 81 端口: 480毫秒(keepalive 之前 503毫秒)
单线程优化前的编译包 82 端口: 500毫秒(keepalive 之前 520毫秒)
docker单线程docker0 83端口:  620毫秒(keepalive 之前 670毫秒)
docker单线程host网络 84端口:  490毫秒(keepalive 之前 520+毫秒)

多线程的测试时间:86 87端口: 180-200毫秒(keepalive之前 900-780毫秒)
核心越多提升越大. 

ab的部分参数解释-1:

-n	即requests,用于指定压力测试总共的执行次数。
-c	即concurrency,用于指定的并发数。
-t	即timelimit,等待响应的最大时间(单位:秒)。
-b	即windowsize,TCP发送/接收的缓冲大小(单位:字节)。
-p	即postfile,发送POST请求时需要上传的文件,此外还必须设置-T参数。
-u	即putfile,发送PUT请求时需要上传的文件,此外还必须设置-T参数。
-T	即content-type,用于设置Content-Type请求头信息,例如:application/x-www-form-urlencoded,默认值为text/plain。
-v	即verbosity,指定打印帮助信息的冗余级别。
-w	以HTML表格形式打印结果。
-i	使用HEAD请求代替GET请求。
-x	插入字符串作为table标签的属性。
-y	插入字符串作为tr标签的属性。
-z	插入字符串作为td标签的属性。

ab的部分参数解释-2:

-C	添加cookie信息,例如:"Apache=1234"(可以重复该参数选项以添加多个)。
-H	添加任意的请求头,例如:"Accept-Encoding: gzip",请求头将会添加在现有的多个请求头之后(可以重复该参数选项以添加多个)。
-A	添加一个基本的网络认证信息,用户名和密码之间用英文冒号隔开。
-P	添加一个基本的代理认证信息,用户名和密码之间用英文冒号隔开。
-X	指定使用的和端口号,例如:"126.10.10.3:88"。
-V	打印版本号并退出。
-k	使用HTTP的KeepAlive特性。
-d	不显示百分比。
-S	不显示预估和警告信息。
-g	输出结果信息到gnuplot格式的文件中。
-e	输出结果信息到CSV格式的文件中。
-r	指定接收到错误信息时不退出程序。
-h	显示用法信息,其实就是ab -help。
原文链接:https://blog.csdn.net/u011415782/article/details/78501799

测试结果的简单结论

1. 使用--net=host 应该比使用单纯的 -p docker0 网络要好很多. 
2. 进行编译优化的二进制应该比不编译优化的二进制要好一些. 但是不是特别明显.
3. 增加了过多的模块可能对性能有影响. 最简化的编译应该是性能最好的. 
4. 基于3的结论,重新编译一个最小化编译的包进行再次验证. 发现包含的模块越少,性能越好.
5. 多次进行ab 的压测与验证, 结论基本上符合这个规律.
6. 平均数较难取得.本次仅使用一个worker 进行测试验证. 机器配置较高.
7. 开启了keepalive 性能会有一定的提升. 所以不管是nginx作为客户端还是服务器端建议开启keepalive

与Nginx调优总结-第六部分编译优化与简单测试相似的内容:

Nginx调优总结-第六部分编译优化与简单测试

第六部分 编译优化 Nginx可以自行编译,所以里面可以设置多个编译策略. 也可以自行修改源码,便于比如进行ip_hash的全IP地址验证. 也可以修改nginx的版本号等信息, 避免内发现. 还可以按照不同的CPU类型进行优化 选择更高级别的优化参数. 不编译debug等的信息,便于降低内存占用等

[转帖]nginx调优参数整理总结

nginx性能优化考虑点 当我需要进行性能优化时,说明我们服务器无法满足日益增长的业务。性能优化是一个比较大的课题,需要从以下几个方面进行探讨: 当前系统结构瓶颈了解业务模式性能与安全 当前系统结构瓶颈 首先需要了解的是当前系统瓶颈,用的是什么,跑的是什么业务。里面的服务是什么样子,每个服务最大支持

TCP内核参数的简单验证

前言 春节假期时学习了下内核参数与nginx的调优 最近因为同事遇到问题一直没有解,自己利用晚上时间再次进行验证. 这里将几个参数的理解和验证结果简单总结一下. 希望能够在学习的过程中将问题解决掉. 其实很后悔没有好好学习代码.现在很多问题都已经到了瓶颈期 无法深入的研究下去. 参数一 net.ip

[转帖]总结:nginx502:Tomcat调优之acceptCount

问题背景:UI页面点击会偶尔返回error,检查调用日志,发现nginx报502报错,因此本文即排查502报错原因。 如下红框可知,访问本机个备机的服务502了,用时3秒左右(可见并不是超时) 先给出原因:是因为tomcat8默认的acceptCount是100,请求量大的时候,会将一些来不及处理的

[转帖]KeenTune调优实践之Nginx调优

https://openanolis.cn/sig/KeenTune/doc/423701433171625827 环境准备 准备两台虚拟机,VM A安装wrk,keentuned,keentune-brain,keentune-bench,作为测试机;VM B安装Nginx,作为Nginx服务端,

[转帖]日更第7日: (翻)nginx调优之使用return代替rewrite做重定向

https://www.jianshu.com/p/26dc6c2b5f43 解释说明 NGINX中重写url的能力是一个非常强大和重要的特性,从技术角度讲return与rewrite均能实现。但使用return相对rewrite更简单和更快,因为计算RegEx会产生额外的系统开销。 Return指

[转帖]Nginx性能调优实战

https://cloud.tencent.com/developer/article/1513125?from=article.detail.1860295 1、Nginx运行工作进程数量 Nginx运行工作进程个数一般设置CPU的核心或者核心数x2。如果不了解cpu的核数,可以top命令之后按1

[转帖]Nginx性能调优实战

https://cloud.tencent.com/developer/article/1513125?from=article.detail.1860295 1、Nginx运行工作进程数量 Nginx运行工作进程个数一般设置CPU的核心或者核心数x2。如果不了解cpu的核数,可以top命令之后按1

[转帖]Nginx性能调优

https://www.jianshu.com/p/024b33d1a1a1/ 本文翻译自Tuning NGINX for Performance Nginx以高性能负载均衡、缓存和web服务器出名,支撑着世界上繁忙网站中的40%。大多数使用场景下,Nginx和Linux系统的默认配置表现较好,但是

[转帖]Nginx应用调优案例

https://bbs.huaweicloud.com/blogs/146367 【摘要】 1 问题背景nginx的应用程序移植到TaiShan服务器上,发现业务吞吐量没有达到硬件预期,需要做相应调优。 2 原因分析l 网卡配置该应用场景下网络吞吐量大,网卡的配置能对性能提升起到很大的作用。l 操作