性能测试实战 30 讲
高楼
前 HP 高级性能专家,7DGroup 创始人
45941 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 37 讲
性能测试实战 30 讲
15
15
1.0x
00:00/00:00
登录|注册

27丨案例:带宽消耗以及Swap(上)

思考题
总结
优化结果
性能问题分析的方式
性能问题分析

该思维导图由 AI 生成,仅供参考

今天我们来看一个真实的案例。事情是这样的,之前有人在微信上问我一个问题,这个问题的现象很典型:典型的 TPS 上不去,响应时间增加,资源用不上。
大概的情况是这样的:有两台 4C8G 的服务器,一台服务器上有 2 个 Tomcat,一台服务器上是 DB。压测的混合场景有 4 个功能模块,其中 3 个访问一个 Tomcat,另外一个访问一个 Tomcat。
Tomcat 的监控页面如下:
应用服务器系统资源监控页面如下:
数据库服务器系统资源监控如下:
JMeter 结果如下:
综上现象就是,单业务场景执行起来并不慢,但是一混合起来就很慢,应用服务器和数据库服务器的系统资源使用率并不高。请问慢在哪?
这是非常典型的询问性能问题的方式,虽然多给了系统资源信息,但是这些信息也不足以说明瓶颈在哪。
为什么呢?在现在多如牛毛的监控工具中,除非我们在系统中提前做好分析算法或警告,否则不会有监控工具主动告诉你, 监控出的某个数据有问题,而这个只能靠做性能分析的人来判断。
我在很多场合听一些“专家”说:性能分析判断要遵守木桶原理。但是在做具体技术分析的时候,又不给人说明白木桶的短板在哪里。这就好像,一个赛车手说要是有一个各方面都好的车,我肯定能得第一名,但是,我没有车。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文通过一个真实案例,介绍了性能问题的分析过程。作者首先强调了性能问题分析需要遵循一定的思路,包括画架构图、描述场景、定位瓶颈等步骤。通过对应用服务器、数据库服务器和压力数据的分析,最终定位到带宽问题导致了性能瓶颈。在分析过程中,作者提到了监控工具的使用、网络带宽的判断、队列堆积等技术细节,展现了对性能问题的深入分析和解决思路。文章内容丰富,技术性强,适合需要了解性能问题分析思路的读者阅读。 在优化结果方面,通过过滤静态资源后再次执行场景,得出了应用服务器带宽、数据库服务器带宽、网络队列和资源监控等数据。这些数据显示了性能的改善,但也出现了Swap问题,为下一篇文章的分析留下了悬念。 总结部分强调了带宽问题在性能分析中的重要性,以及网络瓶颈的判断需要考虑多个因素,如队列长度、网络抖动、丢包、延时等。同时,Swap问题的解决关键在于明白其原理和关联参数。作者提出了思考题,引导读者思考网络瓶颈的判断方法。 整体而言,本文深入剖析了性能问题的分析过程,展现了对技术细节的关注和解决问题的思路,适合对性能问题感兴趣的读者阅读。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《性能测试实战 30 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(22)

  • 最新
  • 精选
  • 土耳其小土豆
    高老师,网络队列的截图的具体命令能告知以下嘛?我想打印跟你那一样的

    作者回复: netstat -naop就可以。

    2020-07-01
    14
  • Geek_9e9d56
    高老师,应用和数据库服务器带宽截图的具体命令能否告知一下?谢谢

    作者回复: 我最常用的就是iftop。

    2021-11-23
    5
  • Geek_Jean
    高老师,谢谢您给大家分享这么多的干货,真的受益非浅,但看完这讲后,我有3个问题没明白: 1. 我有这样一个认知:服务端Send-Q如果有积压,那实时查看网络带宽的时候服务端的发送量和客户端的接收量不会对等。这个认知对吗? 如果上面说的是对的,那我又有一个新问题: 服务端网络资源接收 900KB/s 左右,发送 11M 左右;然后通过查看压力机上的网络接收流量可以看到是93Mbps,换算之后也就是11M左右, 这么看服务端的发送量和客户端的接收量是一样的,带宽是对得上的。依据这样的推断服务端的Send-Q应该不会有积压才对。这个怎么理解呢? 如果上面的认知不对:那我有另外一个新问题: 实时查看服务端的时候Send-Q都有积压了,那说明这些数据还没有到达客户端,那客户端的接收量就不会接近服务端的发送量了。但实际上他们都是93Mbps.这是怎么回事呢?

    作者回复: 有积压时,发送方和接收方的值确实不会对等,但这个偏差很小,你可以查看一下发送方的发送缓冲区大小和内核限制的写缓冲区最大值、以及接收方的接收缓冲区大小和内核限制的读缓冲区大小。 如果你可以在两边抓到同一时刻(记住是同一时刻)的网络带宽,那就会看到区别。 不过我觉得你不用纠结这一点。因为这个队列要长期有值才说明阻塞严重,偶尔有值或间歇性有值是不用关心的。

    2021-09-02
    4
  • Geek_237b86
    老师swapping标黄的是什么工具?

    作者回复: spotlight。

    2020-03-31
    4
  • 糯糯
    老师 有个问题,如果说要找到系统上限,是找到系统瓶颈呢,还是尽可能的压测至服务器资源沾满呢

    作者回复: 瓶颈是上限的绊脚石,得先解决,再把资源占满才有意义。

    2021-04-30
    3
  • bettynie
    高老师,我们做内网测试时采用直连的方式,是不是可以更好的避免内网的网络问题,只考虑网卡的限制,这样可以把精力放在程序本身,先找出比较严重的性能问题再来考虑网络影响?

    作者回复: 如果有必要的话,可以这样做。只是在内网中,网络设备的背板吞吐都是很大的。你的应用有这么大的流量吗?

    2020-04-13
    3
  • 大拇哥
    1)查看服务器发包数量,客户端接口数据包的量是不基本一致,如果出现明显的差别,可以基本确定客户端网络问题 2)查看jmeter聚会报告上面客户端接口数据量是否已经接近宽带的限制 队列: 服务端消息发送队列 客户端接收数据的队列 服务端超时队列

    作者回复: 1,当网络有问题的时候,主要看队列,不用再对比流量了,因为已经没有意义了。 2,对。

    2020-02-21
    2
  • Geek_a8d2eb
    压测时在应用服务上执行命令netstat -naop,发现Recv-Q和send-Q都有间歇性的非0状态,5秒内就恢复0了。网上搜说可接受短暂的非0情况,短暂的Send-Q队列发送pakets非0是正常状态。请问这种说法靠谱么,观察tps和响应曲线也会出现相应的锯齿状

    作者回复: 短暂的非0确实是可能接受的。如果tps和响应时间跟网络队列相关,这就要有证据才可以了。那你需要的是拆分响应时间,看有没有在网络上消耗。

    2021-02-27
    1
  • 😂
    老师,如何判断带宽不够呀?1.服务器接受和发送的流量接近或超过带宽,说明带宽不够?2.压力机接受和发送的流量接近或变过带宽,说明带宽不够?

    作者回复: 看队列。

    2020-12-08
    2
    1
  • nelson
    文稿中提及“综上现象就是,单业务场景执行起来并不慢,但是一混合起来就很慢,应用服务器和数据库服务器的系统资源使用率并不高。请问慢在哪?” 经过一系列分析,没有给出单业务为什么不慢,如果是带宽问题,单业务也一定会慢

    作者回复: 这里提的单业务不慢,是因为对于同样的带宽来说,单业务的TPS是没有业务限定的。而混合场景中会有业务目标限定。

    2020-05-11
    1
收起评论
显示
设置
留言
22
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部