-
Notifications
You must be signed in to change notification settings - Fork 232
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
Merge 1.2-perf into master #442
Conversation
Also removes call to flush the mapred cache used by luke that will be excised in the next release. Only needed for legacy MR.
Mixed clusters do not have riak_kv_put_fsm:start()
Spawn remote vnodes using start_link rather than start.
Conflicts: rebar.config src/riak_kv.app.src
Make riak_client work on non-riak nodes after get/put FSM startup change
Randoming kv_put forwardee node
Nothing else added, so test fails horribly.
If rr is supposed to aborted, it fails, which is good.
This does not mean it's done, it just means it's mostly done, and reasonably correct in implementation.
This allows the get_put_monitor:stop/0 to stop the fake one.
Conflicts: src/riak_kv_sup.erl
Conflicts: src/riak_kv_stat.erl src/riak_kv_stat_bc.erl
…gorithm. If the hard limit was set, but not the soft limit it always read repaired. Changed the soft limit to come from the hard limit if not set and fixed the case where soft==hard triggered a divide-by-zero.
get put stats -> 1.2-perf
Conflicts: rebar.config src/riak_kv_get_fsm.erl src/riak_kv_stat.erl src/riak_kv_sup.erl src/riak_kv_vnode.erl
Node -> | ||
riak_kv_put_fsm:start_link({raw, ReqId, Me}, RObj, Options); | ||
_ -> | ||
proc_lib:spawn_link(Node, riak_kv_put_fsm, start_link, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what was the observed improvement spawning directly rather than using the sup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General waffle about performance near the end.
Merged pretty clean to master (just a conflict with riak_kv_sup over AAE and riak_kv_get_put_monitor.) Tests pass, some poking from the console and it all looks good. Should I benchmark master against this merged (or has that been done, are there numbers?) Apart from comments above +1 from me. |
For performance - I've lost individual figures on improvements. Under heavy load testing the get/put FSM supervisors would build up message queues of several hundred requests. Once the FSMs were started up directly on the client, the 'rex' remote execution server shot to the top of etop and that became a bottleneck - it does extra work around making references and monitoring that we don't require. I retook some measurements when I looked at the original get/put fsm monitor code on the 1.2-perf branch and found that pure load performance was ~10% higher, but it's only when you're really pushing the system that you notice it. |
Increased clarity of some comments, and removed some commented out code.
Ok. Thanks. +1 |
Pull request #442 Conflicts: src/riak_kv_sup.erl
No description provided.