一、Nginx系统结构瓶颈
首先需要了解的是当前系统瓶颈,用的是什么,跑的是什么业务。里面的服务是什么样子,每个服务最大支持多少并发。比如针对Nginx而言,我们处理静态资源效率最高的瓶颈是多大?
可以通过查看当前cpu负荷,内存使用率,进程使用率来做简单判断。还可以通过操作系统的一些工具来判断当前系统性能瓶颈,如分析对应的日志,查看请求数量。也可以通过nginx http_stub_status_module模块来查看对应的连接数,总握手次数,总请求数。也可以对线上进行压力测试,来了解当前的系统的性能,并发数,做好性能评估。
二、业务模式
虽然我们是在做性能优化,但还是要熟悉业务,最终目的都是为业务服务的。我们要了解每一个接口业务类型是什么样的业务,比如电子商务抢购模式,这种情况平时流量会很小,但是到了抢购时间,流量一下子就会猛涨。也要了解系统层级结构,每一层在中间层做的是代理还是动静分离,还是后台进行直接服务。需要我们对业务接入层和系统层次要有一个梳理。
三、性能与安全
性能与安全也是一个需要考虑的因素,往往大家注重性能忽略安全或注重安全又忽略性能。比如说我们在设计防火墙时,如果规则过于全面肯定会对性能方面有影响。如果对性能过于注重在安全方面肯定会留下很大隐患。所以大家要评估好两者的关系,把握好两者的孰重孰轻,以及整体的相关性。权衡好对应的点。
四、性能优化
对相关的系统瓶颈及现状有了一定的了解之后,就可以根据影响性能方面做一个全体的评估和优化。
网络(网络流量、是否有丢包,网络的稳定性都会影响用户请求)
系统(系统负载、饱和、内存使用率、系统的稳定性、硬件磁盘是否有损坏)
服务(连接优化、内核性能优化、http服务请求优化都可以在nginx中根据业务来进行设置)
程序(接口性能、处理请求速度、每个程序的执行效率)
数据库、底层服务
上面列举出来每一级都会有关联,也会影响整体性能,这里主要关注的是nginx服务这一层。
1.文件句柄
在linux/unix操作系统中一切皆文件,我们的设备是文件,文件是文件,文件夹也是文件。当我们用户每发起一次请求,就会产生一个文件句柄。文件句柄可以简单的理解为文件句柄就是一个索引。文件句柄就会随着请求量的增多,进程调用频繁增加,那么产生的文件句柄也就会越多。
系统默认对文件句柄是有限制的,不可能会让一个进程无限制的调用句柄。因为系统资源是有限的,所以我们需要限制每一个服务能够使用多大的文件句柄。操作系统默认使用的文件句柄是1024个句柄。
2.句柄设置方式
·系统全局性修改
·用户局部性修改
·进程局部性修改
3.系统全局修改和用户局部修改
[root@nginx-server ~]# vim /etc/security/limits.conf //最后添加如下
root soft nofile 65535
root hard nofile 65535
soft nofile 25535
hard nofile 25535
#root只是针对root这个用户来限制,soft只是发提醒,操作系统不会强制限制,一般的站点设置(句柄大小)为一万左右就ok了,*代表通配符所有的用户
4.进程局部修改
[root@nginx-server ~]# vim /etc/nginx/nginx.conf
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
worker_rlimit_nofile 65535; #进程限制
events {
worker_connections 1028; #最大连接数
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$http_user_agent' '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'"$args" "$request_uri"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
include /etc/nginx/conf.d/*.conf;
}
主要就是添加work_rlimit_nofile设置句柄数来限制进程,注意events模块的最大连接数就行了。
5.CPU亲和设置
cpu的亲和能够使nginx对于不同的work工作进程绑定到不同的cpu上面去。就能够减少在work间不断切换cpu,把进程通常不会在处理器之间频繁迁移,进程迁移的频率小,来减少性能损耗。
查看cpu核心数
[root@nginx-server ~]# cat /proc/cpuinfo|grep “cpu cores”|uniq
查看cpu使用率
[root@nginx-server ~]#top 回车后按 1
6.配置worker_processes
[root@nginx-server ~]# vim /etc/nginx/nginx.conf
#将刚才查看到自己cpu * cpu核心就是worker_processes
worker_processes 2; #根据自己cpu核心数配置/这里也可以设置为auto
7.CPU配置
假设 配置是2cpu,每个cpu是8核,配置如下:
worker_processes 16;
worker_cpu_affinity 1010101010101010 0101010101010101;
在nginx 1.9版本之后,就帮我们自动绑定了cpu;
worker_cpu_affinity auto;
8.Nginx通用配置优化
#将nginx进程设置为普通用户,为了安全考虑
user nginx;
#当前启动的worker进程,官方建议是与系统核心数一致
worker_processes 2;
#方式一,就是自动分配绑定
worker_cpu_affinity auto;
#日志配置成warn
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
#针对 nginx 句柄的文件限制
worker_rlimit_nofile 35535;
#事件模型
events {
#使用epoll内核模型
use epoll;
#每一个进程可以处理多少个连接,如果是多核可以将连接数调高 worker_processes * 1024
worker_connections 10240;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
charset utf-8; #设置字符集
#设置日志输出格式,根据自己的情况设置
log_format main '$http_user_agent' '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" '
'"$args" "$request_uri"';
access_log /var/log/nginx/access.log main;
sendfile on; #对静态资源的处理比较有效
#tcp_nopush on; #如果做静态资源服务器可以打开
keepalive_timeout 65;
#Gzip module
gzip on; #文件压缩默认可以打开
include /etc/nginx/conf.d/*.conf;
}
五、ab接口压力测试工具
1.简介
ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能,主要是显示你安装的Apache每秒可以处理多少个请求。
[root@nginx-server ~]# yum install httpd-tools -y
[root@nginx-server ~]# ab -n 2000 -c 2 http://127.0.0.1/
-n 总的请求数
-c 并发数
2.参数
-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标签的属性
-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
3.释义
Server Software: nginx/1.10.2 (服务器软件名称及版本信息)
Server Hostname: 192.168.1.106(服务器主机名)
Server Port: 80 (服务器端口)
Document Path: /index1.html. (供测试的URL路径)
Document Length: 3721 bytes (供测试的URL返回的文档大小)
Concurrency Level: 1000 (并发数)
Time taken for tests: 2.327 seconds (压力测试消耗的总时间)
Complete requests: 5000 (的总次数)
Failed requests: 688 (失败的请求数)
Write errors: 0 (网络连接写入错误数)
Total transferred: 17402975 bytes (传输的总数据量)
HTML transferred: 16275725 bytes (HTML文档的总数据量)
Requests per second: 2148.98 [#/sec] (mean) (平均每秒的请求数) 这个是非常重要的参数数值,服务器的吞吐量
Time per request: 465.338 [ms] (mean) (所有并发用户(这里是1000)都请求一次的平均时间)
Time request: 0.247 [ms] (mean, across all concurrent requests) (单个用户请求一次的平均时间)
Transfer rate: 7304.41 [Kbytes/sec] received 每秒获取的数据长度 (传输速率,单位:KB/s)
…
Percentage of the requests served within a certain time (ms)
50% 347 ## 50%的请求在347ms内返回
66% 401 ## 60%的请求在401ms内返回
75% 431
80% 516
90% 600
95% 846
98% 1571
99% 1593
100% 1619 (longest request)
4.示例
·测试机与被测试机要分开
·不要对线上的服务器做压力测试
·观察测试工具ab所在机器,以及被测试的机器的CPU、内存、网络等都不超过最高限度的75%
[root@nginx-server ~]# ab -n 50 -c 2 http://www.testpm.cn/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.testpm.cn (be patient).....done
Server Software: nginx/1.16.0
Server Hostname: www.testpm.cn
Server Port: 80
Document Path: /
Document Length: 612 bytes
Concurrency Level: 2
Time taken for tests: 2.724 seconds
Complete requests: 50
Failed requests: 0
Write errors: 0
Total transferred: 42250 bytes
HTML transferred: 30600 bytes
Requests per second: 18.35 [#/sec] (mean)
Time per request: 108.968 [ms] (mean)
Time per request: 54.484 [ms] (mean, across all concurrent requests)
Transfer rate: 15.15 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 42 52 17.3 46 137
Processing: 43 54 20.8 47 170
Waiting: 42 53 20.7 47 170
Total: 84 106 28.9 93 219
Percentage of the requests served within a certain time (ms)
50% 93
66% 96
75% 101
80% 130
90% 153
95% 161
98% 219
99% 219
100% 219 (longest request)