I just did some similar testing on a single Riak node running on my mac pro dual-quad core w 16gb ram. I concur that smaller values are bounded by. Was running ab -c [1/10/100] -n[1000/10000/100000] from my imac (separate machine). I have found when dealing with such extremely small latencies your environment becomes magnified.
The fact that Wilson is running into lag/timing issues on EC2 is frankly not surprising and notoriously difficult to debug and, imho, not even worth the time barring simple client, server or network stack tweaks. Entirely not related to Riak or EC2 but I love pointing to this article, http://ejohn.org/blog/accuracy-of-javascript-time/. Sure, every millisecond counts but when they are that important you kind of have to go with physical hardware. Multi tenant virtual environments like EC2 should frankly be bared from any performance related discussions as a matter of course. -Alexander Sicular @siculars On Feb 25, 2011, at 2:43 PM, Nico Meyer wrote: > Just out of curiosity I did some tests myself on one of our production > machines. We normally only use the ProtocolBuffers interface and a > thrift interface that we wrote ourselves. > > If I fetch a small key (~250 bytes), the riak server becomes CPU bound > with about 20 concurrent requests, at which point the latency naturally > becomes larger. At this point one riak server is handling over 6000 > requests/s. This is on an 8 core system (Dual Intel Xeon E5506 > @2.13GHz), and all cores are at nearly 100%. No tuning was done on > either riak or the OS. > > Also 99% of the requests still took less then 20ms, while with 10 > concurrent requests its more like 2ms. > > > Am Freitag, den 25.02.2011, 13:54 -0500 schrieb Wilson MacGyver: >> SO_REUSEADDR is also something you set at the socket API as I recall. >> So I don't think it's something you can just set on the TCP/IP itself >> as a global setting. >> >> On Fri, Feb 25, 2011 at 1:41 PM, Les Mikesell <lesmikes...@gmail.com> wrote: >>> Those settings shouldn't make a big difference in how the number of >>> connections scale up, though. There is a theoretical maximum rate limit for >>> creating new connections as each socket is supposed to sit in TIME_WAIT for >>> a packet round-trip time to ensure that nothing outstanding will collide >>> with that socket number when it is reused for the same IP address. Maybe >>> your test is hitting that limit. Can you set SO_REUSEADDR? >> >> > > > > _______________________________________________ > 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
