最近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,准备再测试看看,结果稍候奉上。
分享到:
相关推荐
用好Cache,优化应用 服务集成平台5.6的性能测试进入尾声,这期的优化也算告一段落。这次主要的优化工作还是在三个方面:应用服务器(Apache,JBoss)配置,业务流程,Cache Client包...当前主要采用了以下几点策略:
最近一直在做一个项目的前期设计工作,考虑到后期系统的扩展和性能问题也找了很多解决方法,有一个就是用到了数据库的缓存工具memcached(当然该工具并不仅仅局限于数据库的缓存)。先简单的介绍下什么是memcached。...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
5个目标文件,演示Address EJB的实现,创建一个EJB测试客户端,得到名字上下文,查询jndi名,通过强制转型得到Home接口,getInitialContext()函数返回一个经过初始化的上下文,用client的getHome()函数调用Home接口...
5个目标文件,演示Address EJB的实现,创建一个EJB测试客户端,得到名字上下文,查询jndi名,通过强制转型得到Home接口,getInitialContext()函数返回一个经过初始化的上下文,用client的getHome()函数调用Home接口...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...
BoneCP很小,只有四十几K(运行时需要slf4j和guava的支持,这二者加起来就不小了),而相比之下 C3P0 要六百多K。 异步输出框架 AsynWriter 一个Java的类库,用于异步输出记录的简单小框架用于高并发下数据输出使用...