was this over http GET or protocol buffer? idid you per chance run the test using apachebench also?
On Fri, Feb 25, 2011 at 2:43 PM, Nico Meyer <nico.me...@adition.com> 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? >> >> > > > -- Omnem crede diem tibi diluxisse supremum. _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
