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