稳定性思考-强弱依赖2

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,182元/月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介: 弱依赖“并发请求数阀值”这个值设置多少合适?     “并发请求数阀值”在大部分情况下可以理解为同时工作的线程数阀值,这个值不是越大越好,也不是越小越好,而是在最高QPS输出的情况下这个值越小越好。这个也是系统性能优化的一个方向,高QPS,少线程。     线程它是驱动业务逻辑执行的载体,在执行
弱依赖“并发请求数阀值”这个值设置多少合适?
    “并发请求数阀值”在大部分情况下可以理解为同时工作的线程数阀值,这个值不是越大越好,也不是越小越好,而是在最高QPS输出的情况下这个值越小越好。这个也是系统性能优化的一个方向,高QPS,少线程。
    线程它是驱动业务逻辑执行的载体,在执行逻辑的生命周期中,它会申请各种各样的资源,会占有CPU,会申请内存对象并持有,会申请锁并持有,会申请IO资源并持有,然后再完成一些工作之后,在恰当的时间释放这些资源。如果这个生命周期越长,那么直接导致这些资源被持有的时间越长。导致资源的竞争更加厉害。在java应用中,一个明显的场景就是由于内存申请之后长时间不能释放,导致FULLgC非常频繁。
    另一个角度,因为响应时间变长之后,会直接导致需要更多的线程数来满足不变的QPS,由于线程越多,导致对资源的持有和竞争更加激烈,表现CPU占用很高,Load很高,这是一个恶性循环,需要打破这个环。
    以cache访问为例
    假设客户端app(相对cache而言)本身的输入QPS为200(平均每秒有100个用户请求到此系统),每次业务请求会调用2次Cache,相当于对cache请求的QPS是200*2=400,也就是说如果要满足客户端app 200的qps,那么需要客户端app对Cache有400qps的访问能力,假设客户端app访问cache的平均响应时间为1ms。

    用户--1次请求-->[APP]--2次请求-->[Cache]
根据公式:QPS=1000ms/RT(平均响应时间) * threadNum(并行线程数)
threadNum=QPS/1000 * RT = 400/1000 * 1
                    = 1
Cache响应时间为1ms,那么只需要一个线程就足以提供每秒400次的请求服务,其实理论上1个线程可以提供1000的qps,当然前提条件是cacheServer有非常高的吞吐容量
        我们模拟一下故障
        此时CacheServer发生了故障,对CacheServer的调用全部超时,响应时间变成了3000ms
根据公式计算:threadNum=QPS/1000 * RT = 400/1000 * 3000 =1200
此时需要1200个线程才能满足400QPS的流量 ,换而言之就是客户端会有1200个线程堵塞在CacheServer的访问请求上。这个线程数量早就超过了客户端配置的线程数量,app系统表现为hung住,几乎不能处理任何用户的请求,如果客户端配置的线程数是200,那么根据之前对detail,hesper等java应用系统的压测,200个app线程,会导致系统频繁的发生FullGC(原因是线程数量多,每个线程执行的时间长),此时app的实际QPS反而会比系统极限QPS低很多。
对于APP来说,此时应该是减少对cache的访问量,让少量的线程去试探是否恢复,而不是所有线程都堵塞在这里,原则上来说不管对什么资源的访问,都不能出现大量线程堵塞的情况。
最佳的做法是,限制对cache访问请求的线程数量。比如限制为10: 此时我们再来看一下上面的故障
此时APP的qps仍然为200(假设用户流量不会发生变化),那么可以计算得到app对CacheServer访问的qps变为3:QPS=1000ms/RT(平均响应时间) * threadNum(并行线程数)=1000/3000 * 10 = 3。由于APP只是堵塞了10个线程,超过10个请求后会直接return,并做好return之后相关逻辑处理。app本身并没有因为大量线程消耗大量的资源,app的状态依旧正常,只是cache不能命中。
        接下去故障恢复
        由于用户对APP的请求没有堆积,堵塞在访问cache的线程会因为超时设置,导致每隔3秒会有一个堆积请求退出,同时会放入新的线程,一旦cacheserver恢复,即便是1个线程理论上都可以提供1000的qps,所以系统会非常快速的恢复。
从结果上来看,“超时设置”策略是一种对每一个请求都会起作用的策略,而“并发请求阀值限制”策略是对一段时间持续发生系统变慢后才起作用。系统都正常的情况下超时设置会有一定的误杀,但是异常情况下由于超时的设置还是会导致一定线程的堵塞,所以“超时设置”加上“并发请求阀值设置”是一个很好的降级,流控策略,比单独使用一种有更好的效果。
        另外阀值为什么是10,不是20,不是100,关于这个值到底是多少?可以通过计算得到
        还是400QPS为例,对于客户端来说需要提供一个数据:你可以接受cache的响应时间是多少,平均响应时间为1ms,假设我们可以接受的是10ms:
QPS=1000ms/RT(平均响应时间) * threadNum(并行线程数)
threadNum = 400 * 10 / 1000 = 4
4个线程,没错是4个,不过设置4个线程阀值还是太小
如果是接受100ms:
threadNum = 400 * 100 / 1000 = 40
        一般建议设置40个,40个线程阀值的效果等同于设置100ms超时时间。
 另外,对于客户端APP来说可以接受堵塞多少线程?根据性能压测经验,一般平均50ms左右响应时间的java-APP,最好不要超过60,平均响应时间100ms的最好不要超过100。这个值是相对的,和系统有关系,特别是和系统单次请求所需内存开销,响应时间变化有关。
        再谈一下系统的响应时间
        正常情况RT这个值说应该是一个相对固定的值,因为代码的逻辑是一样的,干活的量也是一样的,好比一个卖票的窗口,卖一张票所需要的时间是固定的。那为什么有时候我们买票需要花更多的时间呢?原因是由于需求的QPS大于供给的QPS,我们被进入了排队,我们的时间消耗在了排队和资源争夺。而且一旦这个条件持续满足“需求的QPS大于供给的QPS”,响应时间会越来越慢,慢到无穷的大。
在系统做性能压测的情况下响应时间的曲线一般是这样的:
                                 /
__________________/    x轴压测用户数,y轴响应时间
        虽然响应时间变长,但是QPS不会变高,反而会下降,系统的极限QPS是由系统的瓶颈资源的极限QPS决定的,因为瓶颈资源的极限QPS几乎是一个固定的值,所以决定了系统只有一个最高QPS,听起来好像很奇怪,因为这个值并不会因为系统补充了其他资源而变的更高,有时候有人会认为我增加线程数量,是不是会增加这个最高QPS,答案肯定是不一定的。
相关文章
|
运维 监控 Java
研发规范第十三讲:阿里 - 如何进行项目稳定性建设
研发规范第十三讲:阿里 - 如何进行项目稳定性建设
845 1
|
9月前
|
Java Maven Spring
【SpringBug】lombok插件失效,但是没有报错信息,@Data不能生成get和set方法
解决写了@Data注解,但是在测试文件中生成的反编译target文件Us二Info中没有get和set方法
803 16
|
Java Linux 容器
JVM内存问题之什么是OOM-Killer,它通常会在什么情况下触发
JVM内存问题之什么是OOM-Killer,它通常会在什么情况下触发
333 2
|
机器学习/深度学习 人工智能 运维
智能化运维:基于AI的系统异常检测与自动修复策略
【5月更文挑战第29天】 在现代IT基础设施管理领域,智能化运维正逐步成为推动效率和稳定性的关键因素。本文深入探讨了人工智能(AI)技术在系统异常检测和自动化故障修复中的应用,提出了一个集成的智能运维框架。该框架利用机器学习算法分析历史数据,实时监控关键性能指标,并在检测到潜在问题时触发自动化修复流程。通过这一方法,我们旨在降低人工干预的需求,提高系统的可靠性和业务连续性。
|
测试技术
稳定性思考-强弱依赖
淘宝系统依赖关系比较复杂。A系统依赖B系统资源,当B系统发生故障的时候,A系统势必会被拖累,导致A系统也发生故障                                  图:[ A]--依赖-->[B] 这里的依赖要区分两种情况 1、A强依赖于B     任何强依赖都要尽可能的转化
3638 90
|
算法 芯片 数据库管理
【视野提升】智能座舱SoC芯片应用需求趋势分析
【视野提升】智能座舱SoC芯片应用需求趋势分析
416 0
|
前端开发 测试技术 关系型数据库
异常测试实践与梳理
异常测试,是指通过人为制造异常,检测系统的处理是否符合逻辑。结合在A项目中的实践,梳理一下常见异常测试的类型、关注点及常用测试工具等。
7713 0
idea2023安装详情与激活码
详情请看:docs.qq.com/doc/DVHhaSHZCaFJKd0Rq
1133 1
|
Java Maven
pom.xml出现“java.lang.OutOfMemoryError: Java heap space”问题的解决办法
pom.xml出现“java.lang.OutOfMemoryError: Java heap space”问题的解决办法
1050 1
pom.xml出现“java.lang.OutOfMemoryError: Java heap space”问题的解决办法
|
Web App开发 Linux 网络安全

热门文章

最新文章