tuning riak for 100s of concurrent connections

Wilson MacGyver wmacgyver at gmail.com
Fri Feb 25 15:27:26 EST 2011


right, which is why I purposely accuess the same one over and over again.
and disable access to the riak cluster from all other systems.

On Fri, Feb 25, 2011 at 3:00 PM, Alexander Sicular <siculars at gmail.com> wrote:
> os level cache caches chunks but shuffles when your access pattern is... random. caveat lots of factors.
>
> -Alexander Sicular
>
> @siculars
>
> On Feb 25, 2011, at 2:57 PM, Wilson MacGyver wrote:
>
>> It's not an actual use case. the actual use case is in fact fairly
>> random access pattern to
>> the keys.
>>
>> it's however a 6 node system, with 3 copies. I'd assume riak can cope with this.
>>
>> I'd also figure the OS level cache would cache the bitcask chunk pretty quickly.
>>
>> On Fri, Feb 25, 2011 at 2:38 PM, Ryan Zezeski <rzezeski at gmail.com> wrote:
>>>
>>>
>>> On Fri, Feb 25, 2011 at 12:45 PM, Wilson MacGyver <wmacgyver at gmail.com>
>>> wrote:
>>>>
>>>>  I purposely have it grab the same key/value over and over
>>>> again.
>>>>
>>>
>>> Could the fact that your getting the same key for each request also be a
>>> factor here?  Wouldn't this mean high contention on those vnodes?  Is this
>>> an actual use case?
>>> -Ryan
>>>
>>
>>
>>
>> --
>> Omnem crede diem tibi diluxisse supremum.
>>
>> _______________________________________________
>> riak-users mailing list
>> riak-users at lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>



-- 
Omnem crede diem tibi diluxisse supremum.




More information about the riak-users mailing list