ben-manes commented on PR #23052: URL: https://github.com/apache/pulsar/pull/23052#issuecomment-2241280440
The expiration is a bit of a red haring because it forces the slower path of periodic maintenance, etc. The maximum size would too, except the benchmarks set that to be 10x the populated size and tracking only begins when it is 50% full. This is support if users decide to disable the configuration using an unreachable value, e.g. `Long.MAX_SIZE`, where we shouldn't prematurely allocate the policy history (a frequency histogram). When using `initialCapacity` to force a preallocation then the timings are relatively similar between expiration and maximum size in your benchmark. On my macbook, expiration is half the throughput due to calling the system clock, but when using `ticker(Ticker.disabledTicker())` then its only 20% slower. If adding concurrency to your tests, `@Threads(8)`, then the scaling is more pronounced on my macbook. A size-bounded cache significantly outperforms `testMapComputeIfAbsent` due to the locking (232M/s vs 14.5M/s), which is less pronounced after Java 9's improvements but can be severe if unlucky. When using expiration this drops to 6.5M/s and jumps to 121M/s if using a disabled ticker, showing that the macOS system call is the bottleneck. One could use an alternative time source, like a scheduled task to update a volatile field every second, to mimic Linux's userland approach. I think your benchmark is likely suffering the same system call overhead problem unless you can verify that it is vDSO mapped and that container virtualization is not interfering with it. Since this impacts all usages of the clock, e.g. for log events, it's probably worth checking your deployment target's behavior in case fixing the environment settings needs to be a a deployment step. The specialized cache should certainly be faster, but its unclear if periodically clearing it would cause a latency hiccup as all requests block trying to reload the entry. Since that's unbounded and stale topics are allowed, then it sounds like expiration isn't needed and that part of the performance analysis is moot? You could use a size bounded Caffeine cache without expiration and not worry about the clock source challenges. It's all kind of hard because benchmarks don't truly reflect real world system performance, so things like soft reference caches look wonderful in isolation and fail badly in practice, so it's all a tough juggling act. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
