apache / apache/servicecomb-java-chassis
[BUG] - 频繁获取不存在配置导致性能劣化
- 主要语言
- Java
- 星标
- 1.9k
- 派生
- 814
- 平均合并
- 8 天 23 小时
- 30 天内合并 PR
- 1
描述
### Steps to Reproduce
servicecomb3.2.2版本问题,性能劣化,火焰图分析:
org.apache.servicecomb.router.custom.RouterServerListFilter#enabled,
org.apache.servicecomb.loadbalance.LoadBalanceFilter#getOrCreateLoadBalancer调用org.apache.servicecomb.loadbalance.Configuration#getRuleStrategyName,
org.apache.servicecomb.loadbalance.filter.ZoneAwareDiscoveryFilter#enabled,
org.apache.servicecomb.registry.discovery.InstanceStatusDiscoveryFilter#enabled,
org.apache.servicecomb.core.invocation.InvocationFactory#setSrcMicroservice调用readServiceName(),每次consumer调用都要重复去spring获取上面五个属性,导致consumer操作CPU消耗比2.X多近10倍
### Expected Behavior
_No response_
### Servicecomb Version
_No response_
### Additional Context
_No response_
贡献指南
这个仓库没有索引到贡献指南
调研方向
首先跟踪经过 RouterServerListFilter#enabled、LoadBalanceFilter#getOrCreateLoadBalancer、Configuration#getRuleStrategyName、ZoneAwareDiscoveryFilter#enabled、InstanceStatusDiscoveryFilter#enabled 和 InvocationFactory#setSrcMicroservice/readServiceName 的每次调用路径。使用 profiling 或针对性测试来验证这五个属性是否被反复从 Spring 中获取。已完成的标准是,所报告的 consumer CPU 回归问题已得到解决,并且受影响的行为仍由测试覆盖。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- java
- 领域
- backend, performance
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 停滞
- 描述清晰度
- 需要澄清
- 新手友好度
- 25/100