Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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
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.