其他分享
首页 > 其他分享> > 性能测试中TPS曲线上下抖动原因定位

性能测试中TPS曲线上下抖动原因定位

作者:互联网

 

 

 

 

 

 

在一个项目短链服务性能测试时,发现一个因为测试客户端造成的吞吐量异常波动的情况,最终原因是在域名多ip的情况下,测试客户端处理不当造成的。但涉及到的知识面包括JVM、DNS缓存,所以来详细说一下。

选用的测试工具是 grindergrinder是纯java实现的负载测试工具

并发策略,并发1个进程,10个线程,测试10分钟。

问题表现:测试发现整体性能还算平稳,但是吞吐量毛刺比较多,且波动浮动比较大。如下图表现:

性能测试中TPS曲线上下抖动原因定位

根据图示中的 Transaction per second 波动曲线发现每个20~30s左右就会出现一次抖动,抖动幅度较大,tps成倍的下降。

这个时候观察两个nginx节点,发现每隔20~30s两个nginx会切换一次,也就是说同一时间只有1个nginx是有压力的,过20~30s之后,压力切换到另一个nginx上。

显然这种情况是不合理的,两个nginx节点是均等的,压力也应该是均衡的,因此怀疑负载均衡会有问题,于是开始分析为什么Nginx会出现这个情况。

分析思路1:是否是DNS负载均衡有问题?

DNS解析多ip的策略是依次返回两个IP顺序为:AB,BA,AB...以此类推,得验证这个机制是否生效。

于是设置java启动参数:-Dsun.net.inetaddr.ttl=0 也即是不缓存ip,每次都进行DNS解析,tcpdump查看数据包实际情况。从dump数据来看,每次域名解析返回的ip地址顺序没问题,是均衡的。所以问题不在Nginx这端,那就可能是客户端使用ip的时候出现了问题。

11:48:11.333446 IP 10.122.104.7.domain > 10.122.104.134.59030: 45250 2/6/6 A 221.222.198.143, A 221.222.198.142 (269)
11:48:11.333558 IP 10.122.104.7.domain > 10.122.104.134.59030: 36926 0/1/0 (79)
11:48:11.333804 IP 10.122.104.134.41170 > 10.122.104.7.domain: 64301+ A? xxx.im. (24)
11:48:11.333816 IP 10.122.104.134.41170 > 10.122.104.7.domain: 19384+ AAAA? xxx.im. (24)
11:48:11.334223 IP 10.122.104.7.domain > 10.122.104.134.41170: 19384 0/1/0 (79)
11:48:11.334393 IP 10.122.104.7.domain > 10.122.104.134.41170: 64301 2/6/6 A 221.222.198.142, A 221.222.198.143 (269)
11:48:11.334641 IP 10.122.104.134.38868 > 10.122.104.7.domain: 784+ A? xxx.im. (24)
11:48:11.334653 IP 10.122.104.134.38868 > 10.122.104.7.domain: 33591+ AAAA? xxx.im. (24)
11:48:11.335108 IP 10.122.104.7.domain > 10.122.104.134.38868: 33591 0/1/0 (79)
11:48:11.335268 IP 10.122.104.7.domain > 10.122.104.134.38868: 784 2/6/6 A 221.222.198.143, A 221.222.198.142 (269)
11:48:11.335344 IP 10.122.104.134.38853 > 10.122.104.7.domain: 3519+ PTR? 7.104.120.10.in-addr.arpa. (43)
11:48:11.335574 IP 10.122.104.134.56540 > 10.122.104.7.domain: 12283+ A? xxx.im. (24)
11:48:11.335587 IP 10.122.104.134.56540 > 10.122.104.7.domain: 36627+ AAAA? xxx.im. (24)
11:48:11.335677 IP 10.122.104.7.domain > 10.122.104.134.38853: 3519 NXDomain 0/1/0 (102)
11:48:11.335873 IP 10.122.104.134.48745 > 10.122.104.7.domain: 26073+ PTR? 134.104.120.10.in-addr.arpa. (45)
11:48:11.335922 IP 10.122.104.7.domain > 10.122.104.134.56540: 36627 0/1/0 (79)
11:48:11.336123 IP 10.122.104.7.domain > 10.122.104.134.56540: 12283 2/6/6 A 221.222.198.142, A 221.222.198.143 (269)
11:48:11.336178 IP 10.122.104.7.domain > 10.122.104.134.48745: 26073 NXDomain 0/1/0 (104)
11:48:11.336378 IP 10.122.104.134.54979 > 10.122.104.7.domain: 37093+ A? xxx.im. (24)

分析思路2:是否是java测试客户端jvm DNS缓存问题?

在域名解析为ip地址后,资源ip地址会保存到JVM缓存中

查看了google大致有两种说法:

1. jdk1.5和1.5之前的版本默认情况下,-Dsun.net.inetaddr.negative.ttl=-1 永久缓存。也就是应用启动之后第一次DNS解析成功后结果会一直cache。

2. jdk 1.6以后与security manager策略有关。安全策略配置文件,

JAVA_HOME/jre/lib/security/java.security

如果没有启用security manager ,默认DNS 缓存时间30秒

# The Java-level namelookup cache policy for successful lookups:
#
# any negative value: caching forever
# any positive value: the number of seconds to cache an address for
# zero: do not cache
#
# default value is forever (FOREVER). For security reasons, this
# caching is made forever when a security manager is set. When a security
# manager is not set, the default behavior is to cache for 30 seconds.
#
# NOTE: setting this to anything other than the default value can have
#   serious security implications. Do not set it unless
#   you are sure you are not exposed to DNS spoofing attack.
#
#networkaddress.cache.ttl=-1

那么,DNS解析到的多条记录是采用轮询策略,还是其它策略?

参考了Google上一篇文章,文章里试验数据说明:

在缓存有效期内,取到的IP永远是缓存中全部A记录的第一条,并没有轮循之类的策略。

缓存失效之后重新进行DNS解析,因为每次域名解析返回的A记录顺序会发生变化,所以缓存中的数据顺序也变了,取到的IP也变化,这和本次测试的现象吻合。

找到原因后,验证多进程多线程的并发策略,结果如下:

性能测试中TPS曲线上下抖动原因定位

测试之后发现tps波动趋于稳定,由此可见这个性能问题,是由于测试客户端在域名多ip的情况下,单进程并发模式造成的,所以我们测试同学在测试时候不要完全相信现有工具,比如你用jmeter做负载,那么多进程的问题jmeter就没法实现,这时候需要我们具备多成熟工具的使用经验或者是自己coding实现多进程多线程的压测请求。

思考:不进行多线程并发,仅改变客户端的java.security配置,networkaddress.cache.ttl=0 进行测试,会有什么样的结果?

欢迎对软件测试感兴趣的朋友加群交流

标签:domain,104.134,48,抖动,IP,曲线,10.122,TPS,104.7
来源: https://blog.csdn.net/Maggie97/article/details/122195372