测试场景:在4C8G机器下跑com.alibaba.csp.sentinel.benchmark.SentinelEntryBenchmark的testSingleThreadDirectly、testSingleThreadSingleEntry
对比1.8.5和1.7.0,发现1.8.5性能损耗较严重
组长度 | 1.8.5 Baseline (QPS) | 1.8.5 With Sentinel (QPS) | 1.8.5 性能损耗 | 1.7.0 Baseline (QPS) | 1.7.0 With Sentinel (QPS) | 1.7.0 性能损耗 | 官方 Baseline (QPS) | 官方 With Sentinel (QPS) | 官方 性能损耗 |
---|---|---|---|---|---|---|---|---|---|
length=25 | 524112.631 | 277096.821 | 47.13% | 551245.089 | 364269.65 | 33.92% | 604589.916 | 401687.765 | 33.56% |
length=50 | 205371.625 | 151465.386 | 26.25% | 213939.277 | 179810.663 | 15.95% | 221307.617 | 192407.832 | 13.06% |
length=100 | 89676.053 | 78605.025 | 12.35% | 92361.784 | 85894.033 | 7.00% | 97673.228 | 91535.146 | 6.28% |
length=200 | 40003.392 | 37519.764 | 6.20% | 41446.589 | 39917.156 | 3.69% | 43742.96 | 42711.129 | 2.36% |
length=500 | 13942.424 | 13677.998 | 1.90% | 14563.868 | 14378.434 | 1.27% | 15332.924 | 15171.024 | 1.06% |
length=1000 | 6392.317 | 6282.31 | 1.72% | 6624.78 | 6588.871 | 0.54% | 7012.848 | 6984.036 | 0.41% |
4条答案
按热度按时间rdlzhqv91#
大概看了一下
1.8.5
的损耗更大是因为com.alibaba.csp.sentinel.util.TimeUtil
获取时间戳导致的,这项改动是在1.8.2
的时候改的,pr #1746 .1.8.2之前单线程定时获取时间戳,逻辑简单损耗小。本地尝试退回低版本逻辑后,损耗与1.7.0相近都是30%左右.
kyvafyod2#
减少2次对volatile变量的读取,减少一次原子递增(去掉writes,只有记录日志的时候会用到),可以提高一些性能
测试结果
修改前:
Iteration 1: 389147.172 ops/ms
Iteration 2: 389936.648 ops/ms
Iteration 3: 389672.101 ops/ms
Iteration 4: 391088.041 ops/ms
Iteration 5: 390817.670 ops/ms
修改后:
Iteration 1: 473274.648 ops/ms
Iteration 2: 473249.861 ops/ms
Iteration 3: 473374.149 ops/ms
Iteration 4: 473110.630 ops/ms
Iteration 5: 471155.953 ops/ms
wr98u20j3#
cc @jasonjoo2010
piwo6bdm4#
刚开始研究sentinel,关于这个类(TimeUtil)是不是可以进一步优化一下,看一下是否可行
1、调用量的统计是否可以使用Constants.ENTRY_NODE中的统计结果,这样获取时间戳的时候就不用单独统计了
2、获取时间戳的代码进一步优化,对volatile变量只做必要的读取。