Nginx性能优化

Cyylog

发布于 2020-08-19 10:33:30

9490

发布于 2020-08-19 10:33:30

文章被收录于专栏：Cyylog技术Cyylog技术

当我需要进行性能优化时，说明我们服务器无法满足日益增长的业务。性能优化是一个比较大的课题，需要从以下几个方面进行探讨

当前系统结构瓶颈
了解业务模式
性能与安全

1、当前系统结构瓶颈

首先需要了解的是当前系统瓶颈，用的是什么，跑的是什么业务。里面的服务是什么样子，每个服务最大支持多少并发。比如针对nginx而言，我们处理静态资源效率最高的瓶颈是多大？能支持多少qps访问请求？怎么得出系统当前的结构瓶颈？

可以通过查看当前cpu负荷，内存使用率，进程使用率来做简单判断。还可以通过操作系统的一些工具来判断当前系统性能瓶颈，如分析对应的日志，查看请求数量。也可以通过nginx http_stub_status_module模块来查看对应的连接数，总握手次数，总请求数。也可以对线上进行压力测试，来了解当前的系统能性能，并发数，做好性能评估。

2、了解业务模式

虽然我们是在做性能优化，但还是要熟悉业务，最终目的都是为业务服务的。我们要了解每一个接口业务类型是什么样的业务，比如电子商务抢购模式，这种情况平时流量会很小，但是到了抢购时间，流量一下子就会猛涨。也要了解系统层级结构，每一层在中间层做的是代理还是动静分离，还是后台进行直接服务。需要我们对业务接入层和系统层次要有一个梳理

3、性能与安全

性能与安全也是一个需要考虑的因素，往往大家注重性能忽略安全或注重安全又忽略性能。比如说我们在设计防火墙时，如果规则过于全面肯定会对性能方面有影响。如果对性能过于注重在安全方面肯定会留下很大隐患。所以大家要评估好两者的关系，把握好两者的孰重孰轻，以及整体的相关性。权衡好对应的点。

4、系统与nginx性能优化

大家对相关的系统瓶颈及现状有了一定的了解之后，就可以根据影响性能方面做一个全体的评估和优化。

网络（网络流量、是否有丢包，网络的稳定性都会影响用户请求）
系统（系统负载、饱和、内存使用率、系统的稳定性、硬件磁盘是否有损坏）
服务（连接优化、内核性能优化、http服务请求优化都可以在nginx中根据业务来进行设置）
程序（接口性能、处理请求速度、每个程序的执行效率）
数据库、底层服务

上面列举出来每一级都会有关联，也会影响整体性能，这里主要关注的是nginx服务这一层。

1、文件句柄

在linux/unix操作系统中一切皆文件，我们的设备是文件，文件是文件，文件夹也是文件。当我们用户每发起一次请求，就会产生一个文件句柄。文件句柄可以简单的理解为文件句柄就是一个索引。文件句柄就会随着请求量的增多,进程调用频繁增加，那么产生的文件句柄也就会越多。

系统默认对文件句柄是有限制的，不可能会让一个进程无限制的调用句柄。因为系统资源是有限的，所以我们需要限制每一个服务能够使用多大的文件句柄。操作系统默认使用的文件句柄是1024个句柄。

2、设置方式

系统全局性修改
用户局部性修改
进程局部性修改

3、系统全局性修该和用户局部性修改

[root@server ~]#vim /etc/security/limits.conf

在文件最下面找到

#*               soft    core            0
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4

#root只是针对root这个用户来限制，soft只是发提醒，操作系统不会强制限制,一般的站点设置为一万左右就ok了
root soft nofile 65535
root hard nofile 65535
# *代表通配符 所有的用户
*    soft nofile 25535
*    hard nofile 25535

可以看到root和，root代表是root用户，代表的是所有用户，后面的数字就是文件句柄大小。大家可以根据个人业务来进行设置。

4、进程局部性修改

[root@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  1024;
}

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;
}

worker_rlimit_nofile 是在进程上面进行限制。

5、cpu的亲和配置

cpu的亲和能够使nginx对于不同的work工作进程绑定到不同的cpu上面去。就能够减少在work间不断切换cpu，把进程通常不会在处理器之间频繁迁移，进程迁移的频率小，来减少性能损耗。nginx 亲和配置

查看物理cpu

[root@server ~]#cat /proc/cpuinfo|grep "physical id"|sort |uniq|wc -l

查看cpu核心数

[root@server ~]#cat /proc/cpuinfo|grep "cpu cores"|uniq

查看cpu使用率

[root@server ~]#top  回车后按 1

6、配置worker_processes

[root@server ~]#vim /etc/nginx/nginx.conf

将刚才查看到自己cpu * cpu核心就是worker_processes

worker_processes 2; #根据自己cpu核心数配置

7、cpu亲和配置

假如小菜的配置是2cpu，每个cpu是8核。配置如下

worker_processes 16;
worker_cpu_affinity 1010101010101010 0101010101010101;

配置完成后可以通过下面命令查看nginx进程配置在哪个核上

[root@server ~]#ps -eo pid,args,psr |grep [n]ginx

在nginx 1.9版本之后，就帮我们自动绑定了cpu;

worker_cpu_affinity auto;

5、nginx通用配置优化

[root@server ~]#vim /etc/nginx/nginx.conf
#将nginx进程设置为普通用户，为了安全考虑
user nginx; 

#当前启动的worker进程，官方建议是与系统核心数一直
worker_processes 2;
#方式一， 第一个work进程绑定第一个cpu核心，第二个work进程绑定到第二个cpu核心，依次内推 直到弟16个
#wokrer_cpu_affinity 0000000000000000 0000000000000001 0000000000000010 0000000000000100 ... 1000000000000000

#方式二，当 worker_processes 2 时，表明 第一work进程可以绑定第 2 4 6 8 10 12 14 16 核心，那么第二work进程就绑定 奇数核心
#worker_cpu_affinity 1010101010101010 0101010101010101;

#方式三，就是自动分配绑定
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内核模型
    user 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;   #如果做静态资源服务器可以打开
    #tcp_nodeny     on;   #当nginx做动态的服务时可以选择打开

    keepalive_timeout  65; 

    ########
    #Gzip module
    gzip  on;    #文件压缩默认可以打开
    gzip_disable "MSIE [1-6]\."; #对于有些浏览器不能识别压缩，需要过滤如ie6
    gzip_http_version 1.1;

    include /etc/nginx/conf.d/*.conf;
}
#查看 核心绑定的nginx work进程
[root@server ~]#ps -eo pid,args,psr | grep [n]ginx

6、ab接口压力测试工具

ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求。

# 安装工具
[root@server ~]#yum install httpd-tools

# 使用
[root@server ~]#ab -n 2000 -c 2 http://127.0.0.1/index.html
-n 总的请求数
-c 并发数
-k 是否开启长连接

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标签的属性
-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

2、内容解释

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)

3、示例演示

[root@server ~]#ab -n 50 -c 20 http://walidream.com/sub_module

输出内容

Server Software:        nginx/1.14.1
Server Hostname:        walidream.com
Server Port:            80

Document Path:          /sub_module
Document Length:        169 bytes

Concurrency Level:      20
Time taken for tests:   0.005 seconds
Complete requests:      50
Failed requests:        0
Write errors:           0
Non-2xx responses:      50
Total transferred:      14900 bytes
HTML transferred:       8450 bytes
Requests per second:    9746.59 [#/sec] (mean)
Time per request:       2.052 [ms] (mean)
Time per request:       0.103 [ms] (mean, across all concurrent requests)
Transfer rate:          2836.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       1
Processing:     1    1   0.3      1       2
Waiting:        0    1   0.2      1       1
Total:          1    2   0.3      2       2

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      2
  95%      2
  98%      2
  99%      2
 100%      2 (longest request)

5、注意事项

● 测试机与被测试机要分开

● 不要对线上的服务器做压力测试

● 观察测试工具ab所在机器，以及被测试的前端机的CPU、内存、网络等都不超过最高限度的75%

6、ab性能指标

1、吞吐率（Requests per second）

服务器并发处理能力的量化描述，单位是reqs/s，指的是在某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。记住：吞吐率是基于并发用户数的。这句话代表了两个含义：

● 吞吐率和并发用户数相关

● 不同的并发用户数下，吞吐率一般是不同的

计算公式：总请求数/处理完成这些请求数所花费的时间，即

Request per second=Complete requests/Time taken for tests

必须要说明的是，这个数值表示当前机器的整体性能，值越大越好

2、并发连接数（The number of concurrent connections）

并发连接数指的是某个时刻服务器所接受的请求数目，简单的讲，就是一个会话。

3、并发用户数（Concurrency Level）

要注意区分这个概念和并发连接数之间的区别，一个用户可能同时会产生多个会话，也即连接数。在HTTP/1.1下，IE7支持两个并发连接，IE8支持6个并发连接，FireFox3支持4个并发连接，所以相应的，我们的并发用户数就得除以这个基数。

4.用户平均请求等待时间（Time per request）

计算公式：处理完成所有请求数所花费的时间/（总请求数/并发用户数），即：

Time per request=Time taken for tests/（Complete requests/Concurrency Level）

5.服务器平均请求等待时间（Time per request:across all concurrent requests）

计算公式：处理完成所有请求数所花费的时间/总请求数，即：

Time taken for/testsComplete requests

可以看到，它是吞吐率的倒数。同时，它也等于用户平均请求等待时间/并发用户数，即

Time per request/Concurrency Level

本文参与腾讯云自媒体分享计划，分享自作者个人站点/博客。

原始发表：2019-08-05，如有侵权请联系 cloudcommunity@tencent.com 删除

nginx

apache

压力测试

http

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体分享计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度