So if you are getting close to similar numbers with the memory and bitcask
backends, you know that file IO isn't your bottleneck in the load test. My
guess is that the machine you are running the load with (where you are
running basho_bench) can't keep up with the test. I'm running basho_bench
on a core i7 on the same switch as the riak nodes, so that could be enough
of the difference. Again though, you can beat yourself up trying to just
get what another person gets in a benchmark, so it really comes down to
what you want out of it. What are your app's requirements? What do you
expect to be the requirements a year from now? What do your access patterns
look like, more read heavy or more write heavy?
Right now, you are only doing bulk load experiments, what about
Write/Read/Update that simulate your expected usage pattern? What we have
done in the past as a good test is to do a bulk load like you are doing
with say 10 or 100 million keys. That'll make sure Riak is loaded with a
real world amount of data to start. Then run another pareto distribution
run (using something like {key_generator, {int_to_bin, {pareto_int,
10000000}}}.) with a spread of puts/gets/updates like {operations, [{get,
4},{put, 1},{update, 1}]}.. I'll tell you right now with a two node cluster
you probably aren't going to be happy with the results as that is not how
Riak was designed to work at its best. If you can swing it, add two more
nodes to the test, set N=2 instead of N=1 so you are getting at least some
data safety and run the above. If it meets the need of your app, awesome.
if it doesn't come back and discuss it or try another solution with the
same requirements.
-Jared
<snip'd the history to pass through the mailing-list size requirement>
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
