dyups模块对nginx性能影响的测试

测试名称：

dyups模块对nginx性能影响

 

测试目的：

 

测试不同场景下dyup模块对nginx性能的影响，并以此为参考制定后续优化方案

 

背景介绍：

 

公司采用dyups+tengine实现后端业务的动态发现，随着业务增长以及新平台上线，我们nginx集群中的upstream总节点成倍增长。在此背景下，我们发现节点数较多的大业务集群滚动升级时，nginx集群的响应时间会急剧增加。

 

在公司大佬源码解读和测试后，我们定位到是大致原因是nginx的 worker会定期检查共享内存从队列里读取dyups更新指令，而由于有锁的存在，同一时间只能有一个worker进行dyups更新操作。当dyups变更的集群节点数较多时，dyups更新的时间会比较长，而worker准备执行dyups更新但上一个worker

未完成dyups更新操作时，此worker阻塞住，不会继续处理业务请求。若平台不停调用dyups变更upstream节点，随着时间的推移，阻塞的worker会越来越多，会急剧降低nginx的性能。

 

下面我画一个理想情况下的简单模型介绍一下几种场景

假设worker检查共享内存的时间点是均匀分布的

T1 T2 ... Tn 为worker1 worker2 ... workern 检查共享内存的时间点。一共有n个worker

t1  t2 ... tn 为worker1 worker2 ... workern 更新完dyups的时间点

 

场景1 dyups更新时间小于worker之间检查共享内存时间间隔

此时每个worker更新完dyups时下一个worker还未检查共享内存，此时nginx的响应时间会稍涨，但总体影响较小

 

场景2 dyups更新时间大于worker之间检查共享内存时间间隔

当t1时，worker1 执行完dyups变更，而worker2和worker3会被阻塞住。当t3时，worker4-worker7会被阻塞住。我们可以发现，随着时间推移，阻塞的worker会越来越多

当dyups更新时间 大于 worker检查共享内存时间间隔（dyups_read_msg_timeout ）/ worker数量 时，会必然出现worker阻塞的情况

 

场景3 所有worker被阻塞

tm时，workerm的下一次检查共享内存的轮训间隔已经到了，但workerm 的dyups更新还未完成，此时所有worker 都已经被阻塞住，nginx已经完全无法处理业务请求

 

要注意的是场景2之后由于会存在worker被阻塞的情况，此时nginx性能会处于非常不稳定的状态，线上一定要避免达到此场景

 

测试环境

 

服务器: M02 20×2cores 256GB mem 两台，一台作为nginx服务器，另一台作为后端和客户端服务器

系统版本: CentOS 7.3

nginx版本: Tengine/2.3.2(nginx/1.17.3)

背景流量: 10000 qps 由wrk作为客户端

后端服务: flask * 40 实例，业务平均处理时长 0.1s

 

测试项目

 

1. 变更的集群数量对nginx性能的影响

 

2. upstream总节点数对（1）的影响

 

3. dyups变更持续时间对nginx性能的影响

 

4. dyups变更间隔对nginx性能的影响

 

5. 开启和关闭check模块对dyups模块和nginx性能的影响

 

6. worker 数量对dyups性能的影响

 

测试结果

 

注意：此结果的数据（集群节点数，变更节点数等）只具备参考价值，不具备指导制定线上具体指标的作用

 

1. 变更的集群数量对nginx响应延迟的影响

 

nginx总节点数为10000，变更间隔为1s，dyups变更的集群节点数为300、350、400、450和500时对 nginx性能的影响

 

 

 

2. upstream总节点数对测试1的影响

 

upstream总节点数为10000、9000、8000、7000和6000，变更间隔为1s时，dyups变更的集群节点数对 nginx性能的影响

 

 

3. dyups变更时间对nginx性能的影响

upstream总节点数为10000，变更间隔为1s，变更集群节点数为350时。变更持续时间对nginx性能的影响

4. dyups变更间隔对nginx性能的影响

upstream总节点数为10000，变更集群节点数为350，变更间隔为2s、1.5s、1s、0.5s时，nginx性能的影响

5. 开启和关闭check模块对dyups模块和nginx性能的影响

 

upstream总节点数为10000，变更间隔为1s，只关闭变更集群的主动健康检查，dyups变更的集群节点数对 nginx性能的影响

upstream总节点数为10000，变更间隔为1s，关闭所有upstream主动健康检查，dyups变更的集群节点数对 nginx性能的影响

 

6. worker 数量对dyups性能的影响

 

 

附加测试

在上述测试之外又做了一些关于参数的测试，但未记录数据，下面只说结论

 

dyups_read_msg_timeout 这个指令设置了worker从共享内存中读取指令的时间间隔。

    调整此参数可以有效提高dyups的性能。但由于会影响dyups的时效性，所以调整需要慎重

dyups_trylock off 打开此参数将获得更好的性能，但它可能不稳定，并且当更新请求与其他请求冲突时，您将获得“ 409”。

打开此参数时，当dyups未更新完时，nginx会拒绝新的修改dyups请求，并返回409状态码。这个实际上相当于强制提高了变更dyups间隔，由此避免worker阻塞恶化的场景出现

 

 

优化建议

 

根据上面实验结果，有以下优化方向

1. 减少单台nginx 总upstream节点数

2. 限制客户端调用dyups频率 ，尽量减少修改dyups总时间

3. 调大 dyups_read_msg_timeout （此参数会降低dyups时效性），打开dyups_trylock

4. 弃用check模块，使用其他主动健康检查方式