Hi Bongjae,
>
> Right. But JavaMemCached's IO may be simpler than you thought. It
> seems that it is similar to blocking mode.
> A connection has pre-defined(pre-allocated) read(8k)/write(1M) direct
> buffer and recycles them(Many connections sometimes raised OOM).
Oh, I see now.
> After writing the buffer to the channel in user thread, the thread
> reads packets from channel immediately.
> If I am understanding correctly, a single operation like get and set
> doesn't use the Selector in JavaMemCached and there is no context
> switching.
AFAIK when socket is used in blocking mode it uses Selector (its own).
> So I think that JavaMemCached had a advantage for simple operation.
> But I am not sure(I saw com.schooner.MemCached.BinaryClient,
> com.schooner.MemCached.SchoonerSockIO and etc... simply).
> Actually, I mainly focused multi-key operations like getMulti and
> setMulti. :) But if we can also improve more about single
> operation(GET/SET), it will be great!
I agree. It's just something we can do when we have time. Otherwise
results look very good, especially multi- operations.
Thanks.
WBR,
Alexey.
>
> Thanks!
>
> Regards,
> Bongjae Chang
>
> From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> <mailto:oleksiy.stashok_at_oracle.com>>
> Reply-To: <dev_at_grizzly.java.net <mailto:dev_at_grizzly.java.net>>
> Date: Tue, 31 Jan 2012 11:59:57 +0100
> To: <dev_at_grizzly.java.net <mailto:dev_at_grizzly.java.net>>
> Subject: Re: Benchmarking results of the grizzly-memcached
>
> Hi Bongjae,
>
> thank you very much for sharing results!
> Looks like GrizzlyMemCached implementation is a bit slower than
> JavaMemCached, especially on single client thread scenario.
>
> I wonder what JavaMemCached does differently? May be there is
> something we can improve in Grizzly...
>
> Thanks a lot!
>
> WBR,
> Alexey.
>
> On 01/31/2012 10:10 AM, Bongjae Chang wrote:
>> Hi,
>>
>> I would like to share benchmarking results of grizzly-memcached.
>>
>> I am pleased that the result is good.
>>
>> -----
>> [Server]
>> Memcached v1.4.11: the lastest version, http://memcached.org/
>>
>> [Clients]
>> SpyMemcached v2.7.3: http://code.google.com/p/spymemcached/
>> JavaMemcached v2.6.0:
>> https://github.com/gwhalin/Memcached-Java-Client/wiki
>> Xmemcached v1.3.5: http://code.google.com/p/xmemcached/
>> GrizzlyMemcached
>>
>> Most of clients are almost the lastest versions.
>>
>> [Protocol]
>> Only memcached binary protocol
>>
>> [Test Operations]
>> Get key, Get multi keys, Set key, Set multi keys(only
>> grizzly-memcached supported it)
>>
>> [Test Senario]
>> Thread 1~400, Value 32bytes~256bytes, LoopPerThread 200, Multi key
>> counts 200
>> All keys are different in each threads.
>>
>> [Machine]
>> 1 Server and 1 Client: Both SentOS, JDK 1.6, 16G Ram, 8 Processors,
>> 1Gbit Network
>> -----
>>
>> I just committed benchmarking sources and
>> results(/extras/memcached/benchmark) and the revision is
>> 48e2cb8ba1f1107f142b1f29682bc435726b1513. So you can see other
>> results from trunk.
>>
>> And I will have a blog about grizzly-memcached later.
>>
>> Thanks!
>>
>>
>>
>>
>>
>>
>>
>> Regards,
>> Bongjae Chang
>