nginx、kong、enovy代理转发功能的性能测试结果对比

Tags: gateway 

目录

说明

这篇是API网关Kong学习笔记(十):Kong在生产环境中的部署与性能测试方法的延续,测试环境中的虚拟机换成了物理机,前半部分沿用之前的测试方法,后面的高并发压测使用效率更高的wrk。

kong0.14.3,envoy 1.8.0

访问端:192.168.128.14 32C64G

服务端:192.168.143.241 24C64G

带宽: 1G

UpStream:位于服务端的容器,Go写的Web服务

envoy的配置见Envoy(一):新型L3~L7层访问代理软件Envoy的使用

低并发长连接场景

UpStream: 4C1G容器
Nginx:     20C
Kong:      20C
Envoy:     无设置,默认all

压测命令:

siege -c 16 -b -t 1M -H "Host: webshell.com" 172.16.129.3/ping
siege -c 16 -b -t 1M -H "Host: webshell.com" 192.168.143.241:7000/ping
siege -c 16 -b -t 1M -H "Host: webshell.com" 192.168.143.241:8000/ping
siege -c 16 -b -t 1M -H "Host: webshell.com" 192.168.143.241:9000/ping

envoy关闭了request id和动态统计,只进行代理与nginx、kong的功能保持一致。

测试结果如下,数据单位是k:

并发            1                      16                           32                 64
--------------------------------------------------------------------------------------------
pod     3.167,3.108,3.252     36.875,36.275,36.290     32.620,34.888,31.775    30.475
nginx   2.454,2.505,2.435     42.112,42.242,42.938     36.031,36.020,37.292    37.416
kong    2.094,2.094,2.067     32.576,32.286,32.879     37.381,36.959,36.307    34.285
envoy   2.228,2.228,2.244     37.433,36.836,36.467     36.356,35.037,38.621    35.779

16并发时,upstream的cpu使用率分别是:400%,397%,320%,380%,说明nginx和envoy代理效率更高。

32并发时,upstream的cpu使用率分别是:400%,400%,400%,400%,说明用于代理的资源充分时,最终能达到相似的吞吐。

32并发时,upstream的cpu使用率均为400%,此时nginx、kong、envoy的CPU使用率分别是339%,730%,500%。

Nginx和Kong使用的是多进程模式,cpu使用率采用的是多个进程的cpu使用率的累加值,cpu使用率十位和个位数字浮动较大,百位基本稳定,其中envoy的使用率是440%~520%,变化较为频发。

(By the way,envoy采用的多线程模式,是否存在一定风险?)

如果网关的机器配置与upstream的机器配置相同时,kong和envoy可能会成为性能瓶颈。

注意:这里所说的瓶颈是针对测试时使用的upstream,测试中使用的upsteam收到请求后直接返回“ok”,并且是低并发、长连接,单核tps是非常高的,9k/cpu,实际业务的tps一定是远远低于这个数值的。

网关的资源估算方法

假设网关(可能是多台机器)总共有32核,在仅做代理的情况下,nginx、kong、envoy的tps上限预计分别是:338k,157k,250k。

nginx:   36k * (32/3.4) = 338.8k
kong:    36k * (32/7.3) = 157.8k
envoy:   36k * (32/5.0) = 230.4k 

只要所有upstream的tps上限值累加起来的数值,低于网关的上限,就是安全的。

可以通过估计upstreams的tps上限和统计实际的tps,确定网关需要的资源,例如:

假设业务服务的单核tps上限平均为1.5k(只返回ok的服务的1/6),kubernetes集群共有2000cpu,那么理论上限就是3000k,网关分别需要284cpu,611cpu,417cpu。

而如果业务服务的cpu使用率平均为30%,网关需要的资源可以缩减为:94cpu,203cpu,139cpu,分别是集群cpu总数的5%,10%, 7%。

这种估算方法用到两个关键数值:

1. 业务服务单核tps上限的平均值
2. 业务服务的cpu使用率

这两个数值需要根据实际情况确定,上面用到1.5k和30%,纯粹是假设。

小结

如果开启了envoy的动态统计功能,在32并发、upsteram饱和的情况下,envoy的cpu使用率从500%升高到520%,32cpu的tps理论上限回落到221k,资源需求由139cpu升高到144cpu。

随着网关上植入的功能增加,处理每个请求时执行的cpu指令增加,网关需要的资源和需要增加。

后续会在开启更多网关功能,以及高并发的情况下进一步测试。

高并发长连接场景

测试环境配置:

Upstream:      10C10G
Nginx & Kong:  10 worker,64000 keep alive
Envoy:         10 thread

设置内核参数:

net.ipv4.ip_local_port_range = 1000     65535

用siege压测

测试方法:

siege -c 32 -b -t 1M -H "Host: webshell.com" 172.16.129.4/ping
siege -c 32 -b -t 1M -H "Host: webshell.com" 192.168.143.241:7000/ping
siege -c 32 -b -t 1M -H "Host: webshell.com" 192.168.143.241:8000/ping
siege -c 32 -b -t 1M -H "Host: webshell.com" 192.168.143.241:9000/ping

用siege直接压测pod,使用1000、10000并发时,upstream打不满,发现请求端创建了与并发数相同的进程,可能是进程数量太多导致请求端发送请求的能力受损。 32并发时请求端发送请求的速率最快,对应请求端的32个核,upstream的cpu使用率能够达到800%。

根据之前在虚拟机上压测经验,并发数是upstream的cpu数量的8倍时,整体吞吐最高。 在物理机上将并发数提高到8倍,即80并发时,直连、nginx和kong的压测结果都下降,确信是请求端发送能力不够的原因,因为80并发时upstream的cpu使用率低于32并发时。 另外80并发时,直连、nginx和envoy得到的数据接近,而kong略有提升,也可以佐证这一点:直连、nginx和envoy的测试结果上不去,是因为请求端先到极限了,kong还能略有提升是因为kong的效率比请求端低。

测试结果如下,数据单位是k:

并发            32                        64                        80
----------------------------------------------------------------------------------
pod     71.174,71.362,71.268    61.988,64.439,60.635    58.345,57.745,60.378
nginx   66.504,64.445,67.751    60.923,61.298,59.322    53.374,56.358,58.558
kong    41.143,43.747,41.393    49.480,51.504,50.108    47.624,48.064,48.633
envoy   53.650,55.477,53.832    55.778,56.804,57.438    50.967,51.698,50.280

可以看到随着并发上升,pod、nginx、envoy的测试结果反而开始下降了,这是压测工具性能不够造成的。

用效率更高的wrk压测

换用效率非常高的wrk压测(wrk效率非常非常,可以用10~20%的cpu将目标机器上的多个cpu打满, siege则几乎是一个cpu只能打满对方一个cpu):

git clone https://github.com/wg/wrk.git
cd wrk 
make

wrk使用方法如下:

./wrk -t 32 -c 64 -d 60s -H "Host: webshell.com" http://172.16.129.4/ping

先确定一下怎样为wrk设置线程数/连接数,压测性能更高。

用wrk直接压测upstream,32线程64并发时可以将upstream打满,cpu使用1000%。测试结果如下,数据单位是k:

并发   (线程数/连接数)     
                  32/32                      32/64                   64/64
----------------------------------------------------------------------------------
pod      90.019,89.613,89.636    96.371,96.422,96.430    96.004,95.661,96.009

可以看到32/64的数据比64/64的数据略高,因此后面的压测全部使用32线程,最终压测使用的命令如下:

./wrk -t 32 -c 64 -d 60s -H "Host: webshell.com" http://172.16.129.4/ping
./wrk -t 32 -c 64 -d 60s -H "Host: webshell.com" http://192.168.143.241:7000/ping
./wrk -t 32 -c 64 -d 60s -H "Host: webshell.com" http://192.168.143.241:8000/ping
./wrk -t 32 -c 64 -d 60s -H "Host: webshell.com" http://192.168.143.241:9000/ping

测试结果如下,数据单位是k:

并发   (线程数/连接数)     
                  32/64                      32/640                   32/6400               32/64000
--------------------------------------------------------------------------------------------------------
pod     96.371,96.422,96.430     105.249,105.550,105.115     99.091, 99.999, 99.480    76.787  
nginx   87.901,86.598,85.300     101.160, 95.653, 93.503     91.020, 88.109, 85.642    89.759
kong    54.841,57.519,57.054      57.150, 57.913, 58.023     54.393, 54.639, 54.581    53.568
envoy   74.506,70.040,72.906      84.067, 85.259, 84.015    111.846,107.235, 106.792   163.270

envoy自动控制了与upstream之间的连接数(1000),不会像nginx和kong那样与upsteam建立大量连接,然后在连接数超过upsteam中的设置时频繁断开连接,envoy在连接控制方面比较优秀。

测试过程中为了避免连接断开重连的情况,为nginx和kong设置的keepalive数值是64000,观测发现,nginx、kong与upstream之间的连接最高到2~3万,envoy与upstream的连接一直是1000。

6400和64000并发时,pod、nginx、kong开始出现socket连接错误,envoy在6400并发时没有socket连接错误,但存在非200的响应。 因此640并发的测试结果更能反应nginx、kong、envoy的性能差异,6400并发和64000并发时都开始出现连接错误或者非200的响应,测试结果不能反应性能差异。

参考

  1. API网关Kong学习笔记(十):Kong在生产环境中的部署与性能测试方法

推荐阅读

Copyright @2011-2019 All rights reserved. 转载请添加原文连接,合作请加微信lijiaocn或者发送邮件: [email protected],备注网站合作

友情链接:  系统软件  程序语言  运营经验  水库文集  网络课程  微信网文  发现知识星球