-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance review (eprof) - WIP #10
Comments
perf_SUITE results, using block version 3 change Focus just on profiles relevant to the general_api_perf test. LOAD:
HEAD:
GET:
MINI_QUERY
UPDATE
Common themes are, the presence of these functions:
|
Running general_api_perf, random profiles from non-client-facing-node, but under light load (only a single client):
|
Same test - looking at the profile of the client-connected node:
|
Analysing the |
Rerunning the test with 4 clients to make the client-facing node busier. Sample profiles:
|
Some observations of potential issues:
|
Comparing HTTP HTTP API profile on the client-facing node:
Alternate implementation of http using only non-deprecated string functions, and not doing repeated lower-casing for comparison - https://github.com/OpenRiak/riak_kv/tree/nhse-o34-nhskv.i30-getputapi:
Not that webmachine makes heavy use of ETS, hence why ets:lookup/2 is more prominent. However, it is strange that the cost per call increases, rather than the volume of calls |
gen_server_loop/7The problem process may be the eprof analyser!!! the busier the node, the busier its gen_server_loop is when analysing the processes - and I didn't exclude this process from the analysed processes. |
gen_server_loop/7Eliminating the eprof server from the calculation, made little difference to the overall numbers. It looks like sidejob is playing a role here. The sidejob workers are gen_servers, so any process started by sidejob will have a gen_server loop, even if it is a gen_fsm. More than a third of this work appears to be related to One consequence is that stat updates are asynchronous, in that stats will be cast to this pool, and so API requests are not delayed by stats updates. But it does make it very hard to measure the true cost of gathering all the stats. |
There are some potential changes proposed: OpenRiak/riak_kv#25 - allows direct_fetch and direct_stat (bypassing sidejob and its gen_server), and makes them the default OpenRiak/riak_api#2 - avoid ETS lookup for PB registrar (expected to be a very marginal gain) Other potential changes:
|
Some notes and potential performance-related issues to be based on eprof analysis.
Method:
The text was updated successfully, but these errors were encountered: