性能测试-Nginx

一、Nginx测试

1、负载均衡

轮询机制（默认）

雨露均沾，两个请求 --> 后端两台服务器， 每台服务器负责处理一个请求

权重

weight 参数是权重，示例中的意思说明：如果nginx收到4个请求，其中3个请求交割192.168.1.110这台机器进行处理。

        upstream myapp1 {        

              server 192.168.1.110:5000 weight=3;        

              server 192.168.1.109:5000;    

          }
    

 

ip_hash机制

同样的客户端ip，多次请求分配给同一台服务器
        upstream myapp1 {        

           ip_hash;        

           server 192.168.1.110:5000;        
           server 192.168.1

    

2、测试

2.1 集群有效性测试（功能测试）——负载均衡是否生效，是否按策略将讲求分配到不同服务器
    方式一：应用日志分析
        此种方式要求后端开发针对请求有记录日志
        看后端应用系统 有没有对应的处理记录
    方式二：服务器网络监控
        通过网络抓包分析请求
        tcpdump 抓包
            centos安装： yum install tcpdump
            tcpdump -i any
                所有网卡中捕获数据包
            tcpdump -i eth0
                指定网卡中捕获数据包
            tcpdump src 192.168.174.2
                指定IP来源
            tcpdump port 5000
                指定端口
2.2 集群容错测试（功能测试）
    集群节点出现故障，无法提供正常服务（停掉某个服务，看其他服务是否正常处理请求）
    检查 整个集群是否有问题【错误率】
2.3 拓展性测试（性能测试）
    模拟生产场景： 9月份 我们针对 双11 高峰期做性能测试，计算需要多少服务器生产环境的机器配置资源配置，要根据实际情况去增减
    生产环境 动态增加机器
    不做其他的系统优化，只是模拟机器增加，检查是否带来性能提升.109:5000;  

二、Nginx 瓶颈分析

1、资源占用：CPU、内容、网络、磁盘

2、请求是否堆积

active：活跃的连接 总数
read：nginx 接受这个请求读取 用户请求信息
wait：nginx 转发请求给后端应用服务器等待具体的业务结果，大量wait ，后端可能处理太慢了
write：nginx已经拿到请求结果回复给客户端，nginx 写响应内容太慢

关系：active=reading + writing + waiting

在访问效率高，请求很快被处理完毕的情况下，Waiting数比较多是正常的。如果reading +writing数较多，则说明并发访问量非常大，正在处理过程中？？？？

三、调优方向

1、Nginx 工作进程数量

Nginx工作进程数

nginx 开启多个进程：和内存打交道，没有负责业务，请求处理很快，所以采用的是多进程

java 和mysql 是开启多线程：因为处理过程中有大量等待时间（和磁盘打交道），线程消耗资源少，所以选择了线程

进程数量：work_processs CPU内核数;

Nginx运行CPU绑定

worker_cpu_affinity 0001 0010 0100 1000
CPU 执行代码： 4个线程 任务代码指令 都交给一个CPU去运行

Nginx最大打开文件数
    操作系统层面： 文件操作、网络操作、进程 --- 文件描述符
    worker_rlimit_nofile 65535;
    这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀，所以最好与ulimit -n的值保持一致，如果配置过低，nginx 无法跑满效率
    注：文件资源限制的配置可以在/etc/security/limits.conf设置，针对root/user等各个用户或者*代表所有用户来设置。

Nginx事件处理模型
    events {  

        use epoll;  

        worker_connections 65535;  

         multi_accept on;

    }
    work_connections是单个worker进程允许客户端最大连接数，这个数值一般根据服务器性能和内存来制定，实际最大值就是worker进程数乘以work_connections。
    实际我们填入一个65535，足够了，这些都算并发值，一个网站的并发达到这么大的数量，也算一个大站了！
    multi_accept 告诉nginx收到一个新连接通知后接受尽可能多的连接，默认是on，设置为on后，多个worker按串行方式来处理连接，也就是一个连接只有一个worker被唤醒，其他的处于休眠状态，设置为off后，多个worker按并行方式来处理连接，也就是一个连接会唤醒所有的worker，直到连接分配完毕，没有取得连接的继续休眠。当你的服务器连接数不多时，开启这个参数会让负载有一定的降低，但是当服务器的吞吐量很大时，为了效率，可以关闭这个参数

后端请求连接断开连接超时时间
    nginx 请求后端，如果迟迟得不到响应， nginx内部堆积大量请求
    主要目的是保护服务器资源，CPU，内存，控制连接数，因为建立连接也是需要消耗资源的

gzip 调优
    这个场景： 压缩静态文件，减少网络带宽占用
    使用gzip压缩功能，可能为我们节约带宽，加快传输速度，有更好的体验，也为我们节约成本，所以说这是一个重点
    gzip on;   #开启压缩功能
    gzip_min_length 1k ：设置允许压缩的页面最小字节数，页面字节数从header头的Content-Length中获取，默认值是0，不管页面多大都进行压缩，建议设置成大于1K，如果小与1K可能会越压越大。
 
expires 缓存调优
    1. nginx  -- 把文件从 磁盘 加载到内存，缓存起来
    还可以作为一个 web 服务器 -- 部署静态的资源{html、图片....}直接返回 文件内容
    nginx 不仅仅只能做负载均衡
    2. nginx -- 主动在返回客户端的消息体，加上 客户端缓存的标记
    缓存，主要针对于图片，css，js等元素更改机会比较少的情况下使用，特别是图片，占用带宽大，我们完全可以设置图片在浏览器本地缓存365d，css，js，html可以缓存个10来天，这样用户第一次打开加载慢一点，第二次，就非常快了！缓存的时候，我们需要将需要缓存的拓展名列出来， Expires缓存配置在server字段里面
 

内核参数优化
    

nginx 调优：nginx调优-腾讯云开发者社区-腾讯云

nginx 监控：运维监控系统PIGOSS BSM 如何实现Nginx监控

nginx 学习：nginx-2-讲解与使用_nginx最大并发连接数-CSDN博客