perf: http layer - cache couchdb version #56
I have taken a look at our http stack with erlang:trace and flamegraphs.
So I tried to memoize it, with pretty good looking flamegraph. I got
I re-benchmarked the unclustered interface, but (almost?) all our
Part of the benchmarks was also to run Apache ab and later to run
All benchmarks (also the flamegraph creation) were run using this test
10000 requests, concurrency 120, reading one doc, unclustered
old version, overall run times:
patched version, overall run times:
(4.82 + 4.78) / (4.39 + 4.37) * 100
patched version is 9.5% faster
The text was updated successfully, but these errors were encountered:
Using the application environment would be faster than the cache implemented here. Plus it wouldn't represent a potential failure due to mailbox overflow.
You would, of course, need to hack the version in to the app env somehow - I don't think it's there already.
No need to fetch all the apps from the ets table and filter them twice (by load status and by name) since we already know our app name and it's already loaded.
It turned out that we spend a lot of our time for every request in the function couch_server:get_version which simply gets the current CouchDB version. Patched version is ~9.5% faster for a simple /get on a document. (Almost?) All our of request-handlers are accessing this function so it should be beneficial for large areas of the http layer. We achieve this by not using an expensive ets:filter function internally by avoiding `loaded_applications` but instead using a simple ets:lookup internally by changing to `get_key`.