When you were doing the reads, did you set the r-value to 1? This will speed up reads in a read heavy app because only one node has to be in agreement about the object.
Eric. On Tue, Aug 2, 2011 at 11:22 AM, Matt Savona <matt.sav...@gmail.com> wrote: > Hi all, > > My colleagues and I are evaluating Riak as a persistent, replicated K-V store. > > I have a fairly simple (and not so scientific) test that reads and > writes 5000 objects that are 32K in size. I am particularly interested > in squeezing every last bit of performance out of Riak in a very > read-heavy environment. I want to avoid hitting disk for reads as much > as possible; our entire content set is much larger than could ever be > stored in RAM, but preferably hot/active objects will remain resident > in memory until various conditions may force them to be evicted. While > the content set is quite large, the number of active keys represent a > very small portion of the data which could easily fit in RAM. > > I've been running the same test against Riak given various > combinations of backends and access protocols (HTTP vs. PB). > > My numbers can be seen in this screenshot: > http://img824.imageshack.us/img824/3185/riakperformance.png > > It is quite evident (and perhaps obvious) that Protocol Buffer > performance is noticeably better than HTTP in most cases. > > What is confusing to me is the performance of purely in-memory > backends. Notably, GB Trees and LRU Cache (and even Innostore), at > best took 14s to retrieve 5000 32K objects. The exact same test > against Membase took just 6s. > > Perhaps I'm not comparing apples to apples (Riak in-memory versus > Membase). Do my tests look reasonable and do the numbers look roughly > in-line with expectations? Is there any way to squeeze more juice out > of Riak? A purely in-memory/non-persistent backend will not suffice > for our ultimate needs, but for testing purposes I'm just trying to > see if I can get read performance more in line with what we're seeing > with Membase. We love everything about it, but we haven't yet hit the > performance we were hoping for. > > Thanks in advance! > > - Matt > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
