davisp commented on issue #610: Optimize ddoc cache URL: https://github.com/apache/couchdb/pull/610#issuecomment-311385739 @chewbranca You managed to nerd snipe me for like four days trying to figure out the mem3 and concurrent LRU stuff. For the mem3 bits I think my conclusion is that its not appropriate here. For mem3_shards we wanted to make sure that there would always be progress so we load things outside of the gen_server and send them to cache. Given that its a local db read this isn't the most terrible thing in the world. Although, for ddoc_cache its a clustered fabric call, so if we followed the mem3_shards pattern we'd actually just be putting extra load on other parts of the system like rexi, and the couch_db_updaters at 3x the rate of client requests. So having them funnel through the opener actually makes more sense here. As to the distributed LRU approach for writes I've been playing with a couple different standalone tests to try and get a feel for our maximum throughput with that. So far (with some *extremely* synthetic tests) I think we're looking at topping out at around 200K updates a second (at least on my laptop). However, this test doesn't actually take into account actually evicting things. My plan for today is to write a basho_bench driver to try and gauge the relative throughput between what I've got written now and a second approach based on your direct ets write idea. I'll post results here when I get them. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
With regards, Apache Git Services
