压测过程中网络带宽瓶颈案例分析

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了压测过程中网络带宽瓶颈案例分析相关的知识,希望对你有一定的参考价值。

近期在做一个项目的性能测试时,在打压时发现压力达到100hps后就一直打不上去,同时还会报读redis服务器超时的错误。

查看了下打压服务器的cpu和内存占用,没有发现什么异常。

通过nmon监控服务器资源信息

CPU占用:

技术分享

 

内存占用:

技术分享

 

1、由于会报redis链接超时错误,首先定位到的是redis服务器挂了,找到开发将log中添加具体连接超时的redis服务器ip信息后,重新跑了一遍。

依然会报连接redis服务器超时错误,开发立即查看了下对应ip的redis服务器。发现运行情况没有出现任何问题,各项指标均正常

 

2、查看压力服务器的各项指标来定位问题。

用sar命令看了下磁盘性能,发现每秒写扇区的次数达到300以上,怀疑是写入次数过多导致的,于是查了下开发的脚本,发现开发每一步判断逻辑中都加了写errorlog操作。于是怀疑是写log导致的。

将开发的写log操作大部分都关闭(除了读redis服务器错误)后,重新跑了一下,发现写扇区的次数降到100左右,但是tps依然打不上去。排除了磁盘写入的问题。

 

3、接下来安装了nmon工具后,重新跑了一遍,看了下网络传输,发现tps达到100左右时,网络出口占用为120M/s!这是千兆网卡的满载速率了。于是定位到网络成为主要的瓶颈。

网络I/O传输表:可以发现eth0-write的速率达到120千KB,也就是120M(注意这里的单位是“千”)

技术分享

4、查了下自己的打压脚本,发现部分请求的返回数据大小为4M。果断将请求的返回改为200K后重新打压后,压力可以成功达到2000hps以上。同时也没有再出现读redis超时的错误。

 至此,此次问题排查圆满结束。同时向大家着力推荐一下nmon工具。里面记录的参数很全,基本上定位性能的指标(比如cpu、内存、每个cpu、每个磁盘分区的读写、磁盘busy情况、网络吞吐、网络包数据等)都能够统计到。

 

以上是关于压测过程中网络带宽瓶颈案例分析的主要内容,如果未能解决你的问题,请参考以下文章

性能测试常见瓶颈分析及调优方法

HTTP请求的TCP瓶颈分析

Netty性能压测偶现消息发送时延毛刺案例

6. 堪比JMeter的.Net压测工具 - Crank 实战篇 - 收集诊断跟踪信息与如何分析瓶颈

十网络分析系统

从测试角度分析—导致系统性能达到瓶颈的主要因素有哪些?