高楼的性能工程实战课
高楼
盾山科技 CEO,7DGroup 创始人
19172 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 35 讲
特别放送 (1讲)
结课测试 (1讲)
结束语 (1讲)
高楼的性能工程实战课
15
15
1.0x
00:00/00:00
登录|注册

14 | 用户信息查询:如何解决网络软中断瓶颈问题?

你好,我是高楼。
这节课我们接着来整另一个接口:用户信息查询。通过这个接口,我们一起来看看,当网络软中断过高时,会对 TPS 产生什么样的影响。其实对于这一点的判断,在很多性能项目中都会出现,而其中的难点就在于,很多人都无法将软中断跟响应时间慢和 TPS 所受到的影响关联起来。今天我就带你来解决这个问题。
同时,我也会给你讲解如何根据硬件配置及软件部署情况,做纯网络层的基准验证,以确定我们判断方向的正确性,进而提出具有针对性的优化方案。而我们最终优化的效果,会通过 TPS 对比来体现。

压力数据

我们先来看用户信息查询的压力数据情况如何。因为我们现在测试的是单接口,而用户信息查询又需要有登录态,所以我们要先跑一部分 Token 数据出来,再执行用户信息查询接口。
准备好 Token 数据后,第一次用户信息查询如下:
这个步骤只是试验一下,持续时间长是为了查找问题。从上图来看,这个接口的起点不错,已经达到 750 左右。
不过,性能瓶颈也比较明显:响应时间随着压力线程的增加而增加了,TPS 也达到了上限。对于这样的接口,我们可以调优,也可以不调优,因为这个接口当前的 TPS 可以达到我们的要求。只不过,本着“活着不就是为了折腾的原则,我们还是要分析一下这个接口的瓶颈到底在哪里。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文通过实际案例介绍了解决网络软中断瓶颈问题的技术特点。作者首先分析了用户信息查询接口的压力数据情况,发现响应时间随着压力线程增加而增加,TPS达到上限的问题。通过架构图和拆分响应时间的方法,分析了用户信息查询接口的路径和每一段消耗的时间,发现Member服务上消耗时间较多。在全局监控分析中,作者强调了全局监控的思路,指出了需要有全局计数器和相应的逻辑。作者还分享了一个案例,强调了在性能分析中需要理智地判断客户需求,并提出了对CPU使用率过高的问题的解决方法。最后,作者通过top数据展示了si消耗的CPU较高,强调了对这种数据的关注。整篇文章以实际案例为基础,通过分析思路和具体操作方法,帮助读者了解了解决网络软中断瓶颈问题的技术特点。文章通过案例分析和技术调优,为读者提供了解决类似问题的思路和方法。

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

全部留言(9)

  • 最新
  • 精选
  • 分清云淡
    很好的案例。但是我有几点不同的意见和解读: 1)si% 应该只和包的数量正相关,BGP只是比IPIP多了少了一次封包解包;当然IPIP包的payload肯定要小,极少部分在IPIP模式下的2个包到BGP 合并到了1个,这样才能降si% 2)优化后TPS 提升了但是 US%却下降了,这么不太符合逻辑 我认为改成BGP后,用在网络封包解包的CPU去掉了,这样让出了更多的CPU给US,这才是这次优化的根因,si%只是顺带的一个极小的因素 :)

    作者回复: 1. 你的理解是没错的。这和文中的描述似乎也没有冲突。后面这句“我认为改成BGP后,用在网络封包解包的CPU去掉了,这样让出了更多的CPU给US,这才是这次优化的根因,si%只是顺带的一个极小的因素”,不知道是我们思路上的不同还是对我们对中断的理解不同,在网络中的IP、TCP之间的数据传递是要靠中断来实现的,你说的封包解包的减少,也是中断的减少。所以SI CPU不是顺带的因素。 2. 这个是具体的监控数据,我并没有更改。并且这个也是符合逻辑的。你可以加我微信,我们详细讨论。

    2021-06-04
    6
    9
  • Geek_c2089d
    为什么看到 NET_RX 中断高的时候,我们会想到去测试一下纯网络带宽? 回答:我们的NET_rx的中断高就说明了我们的系统在不断的做网络处理把包给上一层,然而我们在查看当前流量的时候我们发现使用的流量并不大。出现这情况是可能系统都在处理小的网络包,才会造成高频率的网络请求,但是上文已经对队列缓存都设置大了系统能处理合拼更大的包了,但是我们的处理包的频率还是不高,那么只能说我们的网络链路吞吐量就限制在这里,分析了系统中k8s的网络模型,瓶颈在系统接收包后的处理,是这样理解吗?

    作者回复: 逻辑上似乎是合理的哟。

    2021-10-21
    4
  • 道长
    先通过top,查看到si高,再通过cat /proc/soft…(查看导致软中断),查询这条的时候想看动态的变化情况,在命令前加watch cat…,查看到是RX(网络接收导致),再查到中断消耗的带宽大小,并不大,进而想到是是由于网络小包导致,后面有点没太理解为什么想到了网络模式了问题。

    作者回复: 因为在这样的结构中。网络消耗不多,中断又高,所以,我们要查一下网络中断为什么那么高。对于底层网络的传输来说,中断是为了让数据可以正常让上层应用接收而用来一层层往上通知用的。 我们用的是KVM上面部署了K8s,k8s中的网络插件是有不同的网络模式的,所以这里只要想清楚这个层级关系,就明白了为什么要看网络模式了。对于k8s的优化,网络是非常重要的一块内容,在学习k8s的时候,你就会知道k8s网络模式有不同的实现方式,而这些实现方式的区别会导致中断数量有不同。

    2021-04-23
    3
  • Geek_f93234
    老师,请教2个问题: 1.拆分响应时间中,Gateway -Member 中的两个图的右上角:侦察端 ,服务端,客户端这3个怎么理解? 2.为什么Gateway -Member之间消耗的时间取的是服务端消耗的40ms,而不是客户端消耗的60ms呢?

    作者回复: 1. 这个问题,你先查一下skywalking的具体知识吧。 2. 标识的就是被调用方的时间。

    2021-06-07
    2
  • jy
    老师,请问下,多小算小包?如何判断出来是小包的?

    作者回复: 以太网包大小从64-1518字节。抓包就能看到大小。

    2021-07-28
    1
  • Beyond
    老师,问一个小白问题就是: 1. 用户信息查询,我要先做登录的脚本,拿到token,然后在用户信息查询脚本中对应使用,从而才能获得对应用户信息,那在这个基准场景中,登录和获取用户信息脚本要同时跑,那这对单业务用户查询压测有影响吗,这样串联的话,有点感觉像容量场景,可能我对基准场景压测做法就是单接口但业务压测

    作者回复: 如果你只想压用户信息查询,可以先造出一堆token来嘛。

    2021-05-23
    1
  • 小鱼儿吐泡泡
    你好 请教下 — si 消耗的 CPU 有点高了 — 怎么判断si是否合理? 这个依据是 ?

    作者回复: 这个高低倒没有确切的标准,不过这里超过10%了。根据我的经验在3-5%之间比较正常。

    2021-05-20
    1
  • xhkk
    总共用了 50Mb 的带宽,中断就已经达到 10%,也就是说带宽没有完全用满,可是中断已经不低了,这说明我们的数据包中还是小包居多。 这段话的内容是从该段话上面的图片得到的,高老师,请问图片中哪里显示了是50Mb带宽?中断达到10%又是从那个数字判断的? 另外,这个图是通过什么命令得到的?

    作者回复: 50M的带宽在上面图中的最右下角。10%在上面的top命令中的si列。 命令是iftop。

    2021-04-21
    1
  • 测试中的战斗机
    老师,请教您两个问题,还望解答: 1.我们做性能测试时有时候需要直接在生产环境去压,但生产环境有时候没法安装那些监控软件,像这种情况有什么好的办法通过别的途径获取到监控数据吗? 2. 上文中你截图的那些监控网络图是用什么来监控的?

    作者回复: 1. 不明白你说的哪些监控软件不能在生产上去用。生产上的监控应该比测试环境更全才对。你要具体说出哪个不能用,我才能告诉你有没有替换工具。 2. 我不清楚你说的具体是哪个图。我猜你说的应该是iftop。

    2021-08-14
收起评论
显示
设置
留言
9
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部