最新消息:

Nginx 万兆网络环境测试

未分类 admin 4818浏览 0评论

测试目标

本次测试的目标是将nginx作为7层负载均衡软件,应用于万兆环境下,获得

  • 极限性能
  • 在服务质量保证约束条件下的极限性能
  • 提升极限性能的方法
  • 在万兆环境下部署的一般方法和特殊注意事项

同时,由于nginx还作为静态页面的提供者,附带还进行获得nginx作为静态文件服务器的

  • 极限性能
  • 在服务质量保证约束条件下的极限性能
  • 提升极限性能的方法
  • 在万兆环境下部署的一般方法和特殊注意事项

操作系统是一个很大的影响因素,在测试开始,会对操作系统版本进行选择,以确定哪个是更合适的平台。

测试设备

测试设备如下

  • 万兆网卡X520-DA2
  • 万兆交换机DCS-7124SX-F
  • 万兆DA线
  • SNB服务器
  • WSM服务器

测试环境说明

所有测试服务器连接在同一个万兆交换机下,处于同一个网段。

服务器划分为

  • 服务器(以S简称):提供静态或动态页面,次要测试对象
  • 7层负载均衡(以LB简称):提供负载均衡功能,主要测试对象
  • 客户端(以C简称):提供测试压力

特别注意事项

Keepalive

由于LB和S数量少,高RPS情况下,LB如果采用短连接方式连接S,LB的outgoing port会很快用尽。

解决的方法有两种:

  1. S采用多IP配置,模拟众多S的情况,减小每个S所要消耗的LB outgoing port;
  2. LB与S之间采用keepalive连接

短连接的方式下,CPU会有相当一部分消耗在三次握手上,这主要是操作系统开销(小包处理),以及nginx初始化会话上下文的开销。

RPS、PPS与流量吞吐率

极限测试下,PPS考验服务器的CPU能力;而HTTP协议请求头的处理也是CPU密集型任务。

相同流量吞吐率下

  • 较小的响应意味着较高的RPS
  • 当响应小于一个最大TCP报文长度时,响应越小,也意味着PPS越高

极限测试中,需要测试以下三种情形

  • 全部是大报文。可以通过构造响应为一个最大TCP报文长度实现
  • 全部是小报文。可以通过构造响应为最小HTTP响应实现
  • 混合报文。可以通过构造响应为一个或两个TCP报文,一个是最大TCP报文长度,另外一个的长度可以控制,来满足特定的混合比例

流量吞吐率是一个表观指标,但我们更关心的是在带宽足够的条件下,RPS指标(的范围)。

压缩

在我们的实际使用中,LB是不负责压缩的。但测试中需要测试压缩对RPS的影响。需要考察压缩方面的优化方法。

规则集

负载均衡规则集大小对性能会有影响。由于规则集处理开销正比于RPS,测试中应对较大的规则集进行测试以找出影响大小和可能的优化措施。

实际网络情况

一般而言,极限性能是最理想情况。在本次测试中,我们还需要测试接近实际网络情况下的极限性能,这可以通过引入丢包率、延时来模拟。

测试项目

测试一

测试目标:了解nginx的带宽满载的最小文件大小 (web服务器模式),确定之后测试的文件大小上限

测试工具:ab

测试方法:

  1. S上Nginx做简单配置,使其成为web server;
  2. 在C1上使用 <测试工具> 对S测试10000字节文件,每次减小1000字节,至带宽和RPS均为最高为止。
  3. 根据第二步测试情况调整文件大小,以逼近S的带宽恰好满载且CPU占用率最高时的情况,并记录最终的阈值大小和RPS/PPS指标。

测试结果:

文件大小(Bytes) CPU idle(%) 带宽(MBps) PPS
10K 65 1140 606K
3K 12 1135 1060K
2590 0 1088 1138K
1K 0 585 783K

在采用kernel的pktgen发包测试中,苏能达到的最大PPS为1200K。2590Bytes文件测试中的PPS已经很接近纯发包测试的极限,所以最终,最充 分利用CPU和带宽的文件大小是2590Bytes。

测试二

测试目标:了解 nginx 的大致性能(web服务器模式)

测试工具:ab

测试方法:

  1. S上Nginx做简单配置,使其成为web server;
  2. 在C1上使用 <测试工具> 对S分别测试空文件、616字节文件(半个包长度)、1232字节文件(即含header字节数为1448,整TCP包长度)、1 233字节文件(超过一个TCP/IP包大小1字节)和2590字节文件;3. 测试中记录S的网络吞吐量和CPU状况;C1的RPS,PPS指标波动情况。

测试预期:

  1. 吞吐量应超过1Gbps;
  2. 吞吐量接近5Gbps;
  3. 适当调整网卡等其他配置,应使RPS超过50万(原有百兆环境下的极限值)。

初步测试:

1、在CentOS6.2系统上,十次测试平均结果发现空文件的RPS仅为458005,响应时间0.88715ms,S带宽121M,未能达到预期。

2、检查发现CentOS6.2的ixgbe驱动版本为3.4.8,与最新版本差距较大,升级ixgbe驱动至最新版3.11.33。

更新后原先的8核client已经无法压满server,更换Client设备,ab并发由50×8提高到50×24,测试不同的InterruptThrottle Rate条件下数据如下:

1000:

c568fc0

1500:

m15b564f6

2500:

85b1bbd

3500:

335545b51

4500:

m25052f88

根据以上数据可知,在ITR1500的情况下,空文件的RPS最高,对比数据如下:

ITR RPS 带宽(MBps) user% sys% irq%
1000 688425 186.886 30.112 52.936 16.951
1500 691614 187.408 30.125 52.208 17.667
2500 682326 183.277 29.191 53.253 17.556
3500 650367 175.477 26.803 56.732 16.382
4500 630178 169.474 26.417 56.708 16.833

(注:表格中RPS和带宽数据均为峰值,CPU数据为平稳运行期的中间时刻采样值。下同)

所以在新驱动ITR1500的条件下,重新测试616,1232,1233,2590字节的数据:

616:

m2c94d5e6

1232:

3bd4c0bf1

1233:

m1cb568d31

2590

m73a60e041

测试过程出现剧烈的吞吐量波动,在原有的itr1500的条件下服务极不稳定。

总结ITR1500条件下各文件大小的测试数据对比如下:

文件大小(Btyes) RPS 带宽(MBps) CPU usr% CPU sys% CPU irq%
0 691614 187.408 30.125 52.208 17.667
616 586296 459.435 29.583 54.250 16.083
1232 579103 838.146 29.471 50.563 16.048
1233 513099 772.826 28.417 48.875 22.708
2590 418226 1173.760 23.343 41.934 18.216

另经测试,ITR上调到15000后,2590字节文件测试的S吞吐量恢复成稳定满带宽运行。而且支持并发到80×24。对比ITR5000/10000/15000 条件下数据:

ITR5000图

m7333a21

ITR10000图:

m7721129e

ITR15000图:

a58a533

2.59KB文件在不同ITR下的测试数据对比如下:

ITR RPS 带宽(MBps) usr% sys% irq% 错误进程
1500 418226 1173.760 23.343 41.934 18.216 6
5000 418216 1172.530 24.250 55.792 19.667 3
10000 417989 1171.960 24.625 52.958 22.292 2
15000 404330 1132.490 23.802 52.855 23.343 0

测试三

测试目标:了解nginx配置对性能的影响(access_log)

测试工具:ab

测试方法:

  1. S上做简单配置,关闭 access_log 后进行测试;
  2. 再测试关闭 access_log buffer 的情况(对比测试二的 access_log buffer=1024k 的情况)
  3. 在C1上使用 <测试工具> 对S分别测试空文件(ITR为1500)
  4. 测试中记录CPU占用率,网络吞吐量,RPS和平均响应时间指标

测试结果:

1、设置access_log /data/access_log main;的情况:

与关闭日志相比,吞吐量下降,并且无法支持相同数并发(平均有20%的ab进程退出),只能在30×24的并发数情况下完成稳定测试。

604d3126

2、将日志写入SSD磁盘,验证是否有性能提升。

m34c0cd58

由上两图对比,可见虽然将日志写入SSD对RPS稍有提升,但离关闭日志的70万差距甚远,更换SSD没有实质的意义。

3、普通磁盘上设置buffer=1024k参数

5637f0f7

4、设置buffer=64k参数

m3d18099f

5、设置buffer=4k参数

m160f2f0b

可见在使用buffer参数后,RPS明显提升到和关闭日志时一个数量级的水准。而buffer的大小,从4k到1024k,也可以提高10%左右。

测试三各项数据对比如下:

配置 RPS 带宽(MBps) Usr% Sys% irq% 稳定并发
关闭日志 691614 187.408 30.125 52.208 17.667 50*24
打开日志 180148 49.074 8.966 21.337 4.483 30*24
使用SSD 144347 39.179 10.875 25.708 5.750 30*24
buffer4K 588767 159.297 27.613 55.352 16.951 50*24
buffer64K 593022 160.172 26.845 57.065 16.048 50*24
buffer1M 659290 177.959 32.042 51.875 16.000 50*24

测试四

测试目标:了解nginx配置对性能的影响(tcp_nopush off)

测试工具:ab

测试方法:

  1. S上做简单配置,同时关闭tcp_nopush off;
  2. 在C1上使用 <测试工具> 对S分别测试1232字节文件和1233字节文件
  3. 测试中记录网络吞吐量,RPS和PPS指标

测试预期:

根据对TCP_NOPUSH的理解,在关闭此参数的情况下,1232字节文件的rps应该和开启状态下有较大差别。

测试结果:

1232字节文件数据:

当ITR为1500时:

51d7bf661

峰值带宽比测试二中的数据稍差,但是运行不稳定,CPU的波动与rps图相对应,尝试加大并发则有client进程出现connection timeout错误。

加大itr到15000后波动变的比较稳定。但RPS下降到40万,与测试二相差接近30%。数据如下:

m21d6c756

该项测试相关数据对比如下:

配置 RPS 带宽(MBps) Usr% Sys% Irq% 退出进程
tcp_nopush on+ITR1500 579103 838.146 29.471 50.563 16.048 0
tcp_nopush off+ITR1500 543050 817.746 27.095 51.438 21.467 1
tcp_nopush off+ITR15000 393416 593.411 22.458 55.583 21.958 0

测试五

测试目标:了解nginx的大致性能(代理模式)

测试工具:ab

测试方法:

  1. S上nginx做简单配置,使其成为webserver,作为后端;
  2. LB上nginx做简单配置,使其成为L7 HTTP 代理,所有请求代理至S。LB后端keepalive在测试中测试两种情况,即打开和关闭
  3. 在C1/C2上使用 <测试工具> 对LB分别测试空文件、1232字节文件和2590字节文件
  4. 测试中记录S和LB的CPU占用率,网络吞吐量,RPS三个指标

测试预期:

  1. Keepalive关闭时,可能需要对LB的内核参数进行调整才能够完成测试;
  2. Keepalive关闭时,仅调整内核参数可能不够,S需绑定多个IP地址,LB需使用S的多个IP地址;

测试结果:

(注:因为C1/C2的主板架构/CPU配置不一。8核的C2会先于24核的C1结束测试,后半段数据不如前半段稳定,不过单C1运行也基本可以逼近LB极限,不影响 数据采集和判断。)

1、空文件:

m45af05e8

2、1232字节文件

4687c6d4

3、2590字节文件

m449464d4

4、10K字节文件

m3622cdb6

根据测试二的经验,非空文件ITR为15000时表现更稳定,修改后数据如下:

1、1232字节:

9098f14

2、2590字节:

m7d14ebde1

3、10k字节文件

278a77c91

4、100k字节文件

ffd255

关闭proxy_keepalive,使用2台Client测试,并发2400。空文件测试带宽只能压到18MBps,LB和S的CPU idle都在85%以上。平均响应时间长达40ms。限于环境,压力测试无法继续进行。

本测试proxy_keepalive情况时各项数据对比如下:

ITR+文件大小 RPS 带宽(MBps) Usr% Sys% Irq%
ITR1500+0Byte 392406 165.185 39.533 26.647 30.234
ITR1500+1232Bytes 369582 588.209 41.142 28.595 28.929
ITR1500+2590Bytes 296866 898.885 34.250 29.417 36.167
ITR1500+10KBytes 118163 1167.280 17.870 18.319 15.218
ITR15000+1232Bytes 370590 588.422 41.167 28.375 29.208
ITR15000+2590Bytes 297289 897.755 34.890 28.429 35.682
ITR15000+10KBytes 118033 1168.160 21.137 21.426 25.752
ITR15000+100KBytes 11388 1168.890 4.798 12.542 10.522

测试六

测试目标:nginx LB在多域名情况下的性能

测试工具:ab

测试方法:

1、S上nginx做简单配置,使其成为webserver,作为后端;

2、LB上nginx使用我司实际代理配置(800+域名),使其成为L7 HTTP 代理,所有请求代理至S。LB后端keepalive在测试中测试两种情况,即打开和关闭

3、在C1上使用 <测试工具> 对LB分别测试单域名和随机多域名空文件请求

4、测试中记录S和LB的CPU占用率,网络吞吐量,RPS三个指标

测试预期:

多域名代理情况下性能应和直接通过IP访问在一个数量级内。

测试结果:

1、单域名:

m76022a041

2、随机域名。因为测试在2台服务器上一共开启了32个ab进程,即随机选出32个域名做的测试,结果如下:

41f8c534

3、关闭keepalive的情况:

m6f56712d

可见代理模式使用多个domain和upstream配置,对性能没有太大影响。有影响的依然是keepalive是否开启。具体数据对比如下:

测试条件 RPS 带宽(MBps) Usr% Sys% Irq%
IP访问 392406 165.185 39.533 26.647 30.234
单域名 377292 179.832 41.091 26.811 29.559
多域名 384513 185.632 43.297 27.186 28.185
No keepalive 34879 28.310 5.973 7.341 9.083

测试七

测试目标:其他常见server性能对比

测试工具:ab

测试方法:

Resin4pro加临时lisence,默认配置(关闭日志),测试空文件。

测试结果:

m2e7e1790

与nginx的webserver模式对比如下:

Webserver RPS 带宽(MBps) Usr% Sys% Irq%
resin4 44873 32.353 3.884 4.545 10.455
Nginx1.2 691614 187.408 30.125 52.208 17.667

术语及缩写说明

RPS: Requests per Second,每秒请求数

PPS: Packets per second,每秒报文数

附注

生成图片的 GNUplot 脚本见  用gnuplot绘制多图

转载请注明:爱开源 » Nginx 万兆网络环境测试

您必须 登录 才能发表评论!