memcached java client性能测试的几点疑问和说明

最近java memcached client发布了2.6.1版本，号称性能提升了300%，这是相对于原始主干代码来说。这个改进是由国人做的一个分支，首先得向他们致敬，great job。

 

我这里想谈的主要是这个新闻里的性能测试，从他们的测试结果来看java memcached client的性能确实非常优秀。但是我认为这个测试并不能算非常公平的测试，有几点需要开发者来澄清和说明一下。

 

抛开硬件声明不谈，软件上的配置没有说明，比如各个软件的版本，测试的各个client的参数设置没有说明。为了证明xmemcached可以做到比测试中的更优秀，我也做了个简单测试，我测试的场景如下：

 

并发n个(1,10,50,100,300)线程存取memcached数据，数据大小为64字节，存取次数随并发程度递增,读写比例为4:1。测试的客户端用java memcached client 2.6.1和xmemcachd 1.3.3。memcached版本为1.4.5，内存开大为4G。两者的配置如下

 

java memcached client

 

                BasicConfigurator.configure();
		SockIOPool pool = SockIOPool.getInstance();
		pool.setMinConn(10);
		pool.setMaxConn(20);
		pool.setMaxIdle(60 * 60 * 1000);
		pool.setServers(servers.split(" "));
		pool.initialize();

 

xmemcached

 

 

MemcachedClientBuilder builder = new XMemcachedClientBuilder(AddrUtil
				.getAddresses(servers));
builder.setConnectionPoolSize(20);

 

连接数都设置成20个，我们看下测试的结果。

 

java memcached client

 

 

warm up
threads=1,repeats=40000,valueLength=64,tps=9207,miss=0,fail=0,hit=32004,all=40000,hitRate=1.00
threads=10,repeats=40000,valueLength=64,tps=51788,miss=0,fail=0,hit=320040,all=400000,hitRate=1.00
threads=50,repeats=40000,valueLength=64,tps=90019,miss=0,fail=0,hit=1600200,all=2000000,hitRate=1.00
threads=100,repeats=40000,valueLength=64,tps=90610,miss=0,fail=0,hit=3200400,all=4000000,hitRate=1.00
threads=300,repeats=40000,valueLength=64,tps=86025,miss=0,fail=0,hit=9601200,all=12000000,hitRate=1.00

 

xmemcached:

 

threads=1,repeats=40000,valueLength=64,tps=6513,miss=0,fail=0,hit=32004,all=40000,hitRate=1.00
threads=10,repeats=40000,valueLength=64,tps=38763,miss=0,fail=0,hit=320040,all=400000,hitRate=1.00
threads=50,repeats=40000,valueLength=64,tps=102081,miss=0,fail=0,hit=1600200,all=2000000,hitRate=1.00
threads=100,repeats=40000,valueLength=64,tps=124928,miss=0,fail=0,hit=3200400,all=4000000,hitRate=1.00
threads=300,repeats=40000,valueLength=64,tps=149125,miss=0,fail=0,hit=9601200,all=12000000,hitRate=1.00

 

可以看到，在1个或者10个线程并发的时候，xmc确实比java memcached client差，但是随着并发程度的升高，xmc都超过了java memcached client，顶峰可以达到接近15万的tps。那么，如果java memcached client使用更多的连接池呢，比如200个连接，结果如下

 

 

Java-MemCached startup
warm up
threads=1,repeats=40000,valueLength=64,tps=9248,miss=0,fail=0,hit=32004,all=40000,hitRate=1.00
threads=10,repeats=40000,valueLength=64,tps=50881,miss=0,fail=0,hit=320040,all=400000,hitRate=1.00
threads=50,repeats=40000,valueLength=64,tps=87111,miss=0,fail=0,hit=1600200,all=2000000,hitRate=1.00
threads=100,repeats=40000,valueLength=64,tps=87563,miss=0,fail=0,hit=3200400,all=4000000,hitRate=1.00
threads=300,repeats=40000,valueLength=64,tps=85685,miss=0,fail=0,hit=9601200,all=12000000,hitRate=1.00

 

从结果来看，并没有明显的改善。

 

 

软件配置是我想说的第一个测试中没提到的因素。第二个因素是java memcached client 2.6.1去掉了数据压缩功能，那么在测试大数据的时候，是否将其他客户端的数据压缩功能关掉，这个因素对测试结果的影响很大。我将xmemcached的压缩阈值设置成1M，准备再测试看看，结果稍候奉上。

 

 

 

 

LZ 是boyan吧。
呵呵，我一直在xmemcached，挺好用的。

从上面的比较测试来看，xmemcached找到了提升的空间地方(1-10并发数时的性能)。

嗯，我就是伯岩

这个很难提升，低并发的时候，nio比bio要多不少的context switch。

哈哈，boyan不淡定了。不过xmc确实不错,一直在用。期待进一步测试结果。

哈哈，xmemcached还是很v5的。
现在公司里也有2个memcache客户端实现，从他们的性能测试来看，xmemcached的性能还是很难超越。