【问题标题】:Hystrix performance overheadHystrix 性能开销
【发布时间】:2016-12-19 19:35:30
【问题描述】:

我正在使用 Hystrix 来结束我的几个服务调用(调用的 99% 约为 200 毫秒)。我的 hystrix 配置看起来像

- 核心尺寸:80
- executiontimeoutinMilliSeconds : 600
- metricsRollingStatisticalWindowInMilliseconds:10000
- metricsRollingStatisticalWindowBuckets:10
(其余均为默认值。)

一直在我的应用程序中观察到一个奇怪的行为(虽然是间歇性的)。大多数时候,服务调用似乎工作正常,没有任何 hystrix 超时(一个小时左右只有几个调用超时)。
但是偶尔hystrix超时确实会增加很多倍
在分析原因时,我唯一能掌握的是我在 hystrix 中的 execute-latency (我的实际业务逻辑的延迟,在我的 HystrixCommand 的 run 方法中) 远小于 total-latency(hystrix 从在命令上调用 execute() 到获得实际响应所用的总时间)。

问题:
1. 为什么我的执行延迟和总延迟之间有如此大的差异(执行远小于总延迟)。这种开销的可能原因是什么。 (PS:我服务器上的qps几乎没有10)
2. 是否有与此开销相关的文件?我怎样才能找出这里的实际瓶颈?

任何线索将不胜感激。

【问题讨论】:

    标签: performance hystrix


    【解决方案1】:

    我们遇到了完全相同的问题,通过迁移到 1.5.x 解决了这个问题

    引用自-https://github.com/Netflix/Hystrix/releases/tag/v1.5.0

    桶滚动现在通过 Rx 后台线程而不是不幸的 Hystrix 命令线程发生。这使得命令性能更可预测。用户线程延迟现在与命令延迟几乎无法区分。

    【讨论】:

      猜你喜欢
      • 2023-04-01
      • 1970-01-01
      • 1970-01-01
      • 2013-02-09
      • 2018-07-26
      • 1970-01-01
      • 1970-01-01
      • 2013-02-24
      • 1970-01-01
      相关资源
      最近更新 更多