第六部分 编译优化

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调优总结-第六部分编译优化与简单测试的更多相关文章

  1. nginx调优配置

    nginx调优配置 user www www; #工作进程:数目.根据硬件调整,通常等于CPU数量或者2倍于CPU. worker_processes 8; worker_cpu_affinity 0 ...

  2. nginx调优(二)

    nginx调优(一) (1).Fastcgi调优 FastCGI全称快速通用网关接口(FastCommonGatewayInterface),可以认为FastCGI是静态服务和动态服务的一个接口.Fa ...

  3. 记一次单机Nginx调优,效果立竿见影

    一.物理环境 1.系统是Centos 8,系统配置 2核4G,8M带宽,一台很轻的应用服务器. 2.站点部署情况.但站点部署两个实例,占用两个端口,使用nginx 负载转发到这两个web站点.  二. ...

  4. 性能调优之访问日志IO性能优化

    性能调优之访问日志IO性能优化   poptest是国内唯一一家培养测试开发工程师的培训机构,以学员能胜任自动化测试,性能测试,测试工具开发等工作为目标.如果对课程感兴趣,请大家咨询qq:908821 ...

  5. 《高性能SQL调优精要与案例解析》一书谈主流关系库SQL调优(SQL TUNING或SQL优化)核心机制之——索引(index)

    继<高性能SQL调优精要与案例解析>一书谈SQL调优(SQL TUNING或SQL优化),我们今天就谈谈各主流关系库中,占据SQL调优技术和工作半壁江山的.最重要的核心机制之一——索引(i ...

  6. DB-SQL-MySQL-杂项-调优:Mysql千万以上数据优化、SQL优化方法

    ylbtech-DB-SQL-MySQL-杂项-调优:Mysql千万以上数据优化.SQL优化方法 1.返回顶部 1. 1,单库表别太多,一般保持在200以下为宜 2,尽量避免SQL中出现运算,例如se ...

  7. nginx调优(一)

    (1).隐藏nginx版本号 隐藏版本号可以有效避免黑客根据nginx版本信息,查找对应漏洞进行攻击. 下载nginx源码包(http://nginx.org/en/download.html)并上传 ...

  8. nginx调优buffer参数设置

    内容来自 https://blog.tanteng.me/2016/03/nginx-buffer-params/.有空再详细了解 Nginx性能调优之buffer参数设置 打开Nginx的error ...

  9. JVM调优总结(六)-新一代的垃圾回收算法

    垃圾回收的瓶颈 传统分代垃圾回收方式,已经在一定程度上把垃圾回收给应用带来的负担降到了最小,把应用的吞吐量推到了一个极限.但是他无法解决的一个问题,就是Full GC所带来的应用暂停.在一些对实时性要 ...

  10. 《高性能SQL调优精要与案例解析》一书谈SQL调优(SQL TUNING或SQL优化)学习

    <高性能SQL调优精要与案例解析>一书上市发售以来,很多热心读者就该书内容及一些具体问题提出了疑问,因读者众多外加本人日常工作的繁忙 ,在这里就SQL调优学习进行讨论并对热点问题统一作答. ...

随机推荐

  1. 代码也能“杀”虫:此虫,真虫非Bug也

    摘要:看这群大学生如何保护粮食,让害虫.霉变无处遁形. 国以民为本,民以食为天,对有着14亿人口的中国来说,粮食安全,一直都是关系国计民生的头等大事. 2010年以来,我国人均粮食占有量持续高于世界平 ...

  2. 宝藏昇腾AI应用推荐!CANN带你体验黑白图像自动上色的快乐~

    摘要:属于"你"那边的麦田 天空 河水 骏马 树木--会是什么颜色呢? 黑白与色彩 似乎把时代分割了两半~ 我在这头看见了错乱繁华,琳琅满目,看见快速消长的色彩缤纷. 翻开一张黑白 ...

  3. 海量数据分析快准稳!GaussDB(for MySQL) HTAP只读分析特性详解

    摘要:除了拥有 ClickHouse 本身的极致性能外,GaussDB(for MySQL)的HTAP只读分析在 MaterilizeMySQL引擎的性能和稳定性等方面具有更优秀的表现,为提供更快更准 ...

  4. “pip不是内部或外部命令,也不是可运行的程序或批处理文件” 到底有多么神秘

    摘要:pip不是内部或外部命令,也不是可运行的程序或批处理文件到底有多么神秘? 本文分享自华为云社区<揭开「pip不是内部或外部命令,也不是可运行的程序或批处理文件」的神秘面纱>,作者:A ...

  5. COG云原生优化遥感影像,瓦片切分的最佳实践

    摘要:云上遥感影像文件Cloud optimized GeoTIFF(COG)格式的详细介绍,大量数据上云面临的挑战,并分享了获得云原生影像最佳性能的实践经验. 本文分享自华为云社区<COG云原 ...

  6. SQL SERVER数据分组后取第一条数据——PARTITION BY

    MySQL 数据分组后取第一条数据 SQL SERVER (mssql) 数据分组后取第一条数据 SQL 如下 找状态=1的数据,按 HospitalId,DeptId 组合并倒序排序,每组里面取第一 ...

  7. Pymsql简介

    ###### 什么是PyMysql Pymsql是在Python3.x版本中用于连接Mysql服务器的一个库,Python2中则适用mysqldb ###### Pymsql安装 ```python ...

  8. #5702:Solving Order(结构体排序,水题)

    原题目链接 题目大意:把颜色由多到少进行排序,从大到小的输出. 解题思路:将变量存在结构体中,然后结构体排序即可.还需要注意格式的问题. 详见代码. #include <iostream> ...

  9. JVM 内存大对象监控和优化实践

    作者:vivo 互联网服务器团队 - Liu Zhen.Ye Wenhao 服务器内存问题是影响应用程序性能和稳定性的重要因素之一,需要及时排查和优化.本文介绍了某核心服务内存问题排查与解决过程.首先 ...

  10. JavaScript到底应不应该加分号?JavaScript自动插入分号规则详解

    JavaScript 提供了 automatic semicolon insertion (ASI)自动插入分号规则,在不加分号的情况下,会自动补充分号来分隔不同语句. 导致在继左大括号换行.tab ...