Hi Alexey,
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).
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.
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!
Thanks!
Regards,
Bongjae Chang
From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Reply-To: <dev_at_grizzly.java.net>
Date: Tue, 31 Jan 2012 11:59:57 +0100
To: <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
>
>
>
>