nickva commented on PR #5625: URL: https://github.com/apache/couchdb/pull/5625#issuecomment-3200915315
> I'd like to see a bigger benchmark before deciding but the performance gain is quite modest (except for changes) to warrant the extra complexity and failure modes (on the flipside it does validate our deliberate reliance on the OS page cache for this so far). Definitely would need a better benchmark, this was a quick and dirty one mainly to mainly show how many reads we saved with a mix of operations on 100k docs. Since I didn't do any page cache evicting all the block were in the page cache, so it validates our use of the page but it also shows that there is quite an overhead in going through all the IO layers. And since we're aware of the b-tree/header structure at this layer we can make better decisions on what to cache. > I'd be curious to see the same benchmarks but with the code modified to not expire the cached items so aggressively (to find the upper bound to how much this could improve things). Maybe we can make the "don't clean up if fill ratio is below 1/4" setting configurable, and with a large enough cache and a value like 3/4 we could look at the effects. > It would also be useful to know how deep the btrees are in question (or some other indication of the cache hit/miss ratio to give us context when assessing the throughput figures). As for why changes gets such a boost, that needs some thinking. Good idea, maybe we'd want a diagnostic get depth traversal API to get an idea. -- 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: notifications-unsubscr...@couchdb.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
