令人振奋的结果:memcached 访问速度达到66000TPS

今天找了两台服务器进行Memcached Client java的测试，其中
服务器为：
CPU：2* Socket Designation: CPU1  Version: Intel(R) Xeon(R) CPU   E5320  @ 1.86GHz
内存:8G

起8个线程，运行memcached-1.2.6


客户端为：
CPU: 2* Socket Designation: CPU1
        Version: Intel(R) Xeon(R) CPU           E5310  @ 1.60GHz
内存:8G

jdk1.6

代码分支:https://commons-client.googlecode.com/svn/trunk
版本：144


测试多次以后发现，最高达到：66000TPS，基本稳定在61000TPS

评论

25 楼 uniseraph 2008-10-30  

box 写道

代码还没更新上去吧

在dev分支：
http://commons-client.googlecode.com/svn/branches/dev

24 楼 box 2008-10-30  

代码还没更新上去吧

23 楼 uniseraph 2008-10-30  

uniseraph 写道

raymond2006k 写道
楼主， 把你的测试代码也放到 google code上吧。 value长度10和100显然是不一样的哦，性能应该有差异， 要正视大家的关切啊，呵呵。可再做做并发测试，加入网络吞吐的考虑。

如果功能上，性能已经成熟了，可以完善一下你的项目网站，发个 阿尔法 版本了，有时间再补充点文档吧。我最近也在给公司一些项目cache方案选型，以及对比 memchache，Coherence的差异。
你的框架看起来不错，估计有的项目会用你的客户端了，呵呵。


抱歉工作有点忙，所以没有及时回复。

为什么value长度为10和为100性能不能一样?实际上现在的瓶颈已经不在io上，而且我也也实际测试过了。用我的t61连服务器，速度还是在26000左右。

测试代码在这里:http://commons-client.googlecode.com/svn/branches/dev/src/main/java/org/coral/common/memcached/Test.java

另外已经支持链接多个memcached服务器：

MultiTargetMemcachedClient mc = new MultiTargetMemcachedClient();
		mc.addTarget(ip, port);
		mc.init();
byte[] result=mc.set('111')

22 楼 uniseraph 2008-10-30  

raymond2006k 写道

楼主， 把你的测试代码也放到 google code上吧。 value长度10和100显然是不一样的哦，性能应该有差异， 要正视大家的关切啊，呵呵。可再做做并发测试，加入网络吞吐的考虑。

如果功能上，性能已经成熟了，可以完善一下你的项目网站，发个 阿尔法 版本了，有时间再补充点文档吧。我最近也在给公司一些项目cache方案选型，以及对比 memchache，Coherence的差异。
你的框架看起来不错，估计有的项目会用你的客户端了，呵呵。

抱歉工作有点忙，所以没有及时回复。

为什么value长度为10和为100性能不能一样?实际上现在的瓶颈已经不在io上，而且我也也实际测试过了。用我的t61连服务器，速度还是在26000左右。

测试代码在这里:http://commons-client.googlecode.com/svn/branches/dev/src/main/java/org/coral/common/memcached/Test.java

21 楼 raymond2006k 2008-10-29  

楼主， 把你的测试代码也放到 google code上吧。 value长度10和100显然是不一样的哦，性能应该有差异， 要正视大家的关切啊，呵呵。可再做做并发测试，加入网络吞吐的考虑。

如果功能上，性能已经成熟了，可以完善一下你的项目网站，发个 阿尔法 版本了，有时间再补充点文档吧。我最近也在给公司一些项目cache方案选型，以及对比 memchache，Coherence的差异。
你的框架看起来不错，估计有的项目会用你的客户端了，呵呵。

20 楼 Readonly 2008-10-29  

sdh5724 写道

召唤大人们给我个美丽的解决方案啊, 机器贵啊贵啊...节约一台是台.

为啥要多买机器呢，在原有的机器上加内存不就可以了，现在内存白菜价，400可以买2G，400还不够一个资深Java开发人员一天的工资
12000 / 22 ~= 454

19 楼 uniseraph 2008-10-29  

sdh5724 写道

一个对象可以这么做， 我甚至可以通过反射，或者anotation把所有要序列化的数据获得。 但是对象类型多了， 反序列化要确定对象类型是很困难的事情。 BDB的做法是， 把所有要被保存的对象， 获得他的对象类型， 然后独立保存了一份独立的数据表， 反序列化的时候， 查询对象的META来重新组装。
    作为架构人员， 首先要想到的是不是可行， 而不是限制。为系统API设置诸多的限制， 会让程序员痛苦的。

和你理解恰好想法，框架不应该提供无限自由度的，更多的是一种约束，让开发者遵守框架的推荐的开发方式。

就今天这个问题，其实我们的区别在于对一个send的设计，你希望是
void send1(Object obj)

我更喜欢
public interface Command {
     byte[] toBuffer();
}
void send2(Command command);

并非一定是某种更好，但是相对来说，send2的约束更强，send1的自由度高。从你现在这个场景，我觉得send2更合适，而且也简单。

18 楼 sdh5724 2008-10-29  

    一个对象可以这么做， 我甚至可以通过反射，或者anotation把所有要序列化的数据获得。 但是对象类型多了， 反序列化要确定对象类型是很困难的事情。 BDB的做法是， 把所有要被保存的对象， 获得他的对象类型， 然后独立保存了一份独立的数据表， 反序列化的时候， 查询对象的META来重新组装。
    作为架构人员， 首先要想到的是不是可行， 而不是限制。为系统API设置诸多的限制， 会让程序员痛苦的。

17 楼 uniseraph 2008-10-29  

sdh5724 写道

晕死， 自己做， 我当然也能想到， 问题的现实是， 我开发了个API， 给其他程序员用， 还要他们实现外部序列化方法？     就是外部序列化，也会浪费非常多的CLASSINFO的东西， 这个你可以看ObjectOutpuStream。  无论如何， 一个byte[], 要被重新组装回对象就必须付出ClassInfo的存储的代价。    只有通过外部保存CLASSINFO的东西， 才能做到重新组装。

你错了。 并非所有byte[]要重新组装回对象必须付出ClassInfo存储的代价。你想想，以前c/c++时候哪有classinfo，还不是照样完成了。



前面codeutil朋友也说了“javabean实现Externalizable 接口，自己实现byte转换，就可以不依赖描述信息。bdb无非也是用bind接口来干同样的事情而已。 ” 其实就是这个意思。


框架不可能结束所有问题的，所以有些时候还是得对应用开发者有些约束，所以要求他们满足某些约束，例如实现Externalizable接口。我说的IoBuffer也是如此。

16 楼 sdh5724 2008-10-29  

晕死， 自己做， 我当然也能想到， 问题的现实是， 我开发了个API， 给其他程序员用， 还要他们实现外部序列化方法？
    就是外部序列化，也会浪费非常多的CLASSINFO的东西， 这个你可以看ObjectOutpuStream。  无论如何， 一个byte[], 要被重新组装回对象就必须付出ClassInfo的存储的代价。
   只有通过外部保存CLASSINFO的东西， 才能做到重新组装。

15 楼 uniseraph 2008-10-29  

m8x6bmxb 写道

sdh5724 写道uniseraph 写道sdh5724 写道
最近，我陷入一个郁闷。 就是JAVA的序列化问题。 当你向MEMCACHED直接写序列化的对象的时候， 一个对象完整的描述将会被写进memcached。 那么如果写1000W个对象给memcached, 对象描述将会被写无数次。 序列化描述大小往往远远大于对象的实际数据的， 因此， 我们的内存就被大量这些信息浪费了。 谁解决了这个问题？ 我在研究berkleydb java edition的解决方案。 这个问题对于内存节约使用是非常重要的。 我现在4台memcache机器吃了我20G内存， 再涨下去， 就要买机器了。 很不划算啊。


如果你放入的对象很多，对象类型不多，干脆将其转换成byte[]再写入memcached，用IoBuffer实现很简单。




你没有理解我的意思啊, 就是byte[] 也会有ClassInfo的啊. 我是做一个把所有CACHE种类接口统一化的项目.我无法预知用户要保存什么样的对象.  今天我研究了berkely DB java edition的代码, 发现他们是按照把存入对象的顺序, 把对象类型进行编号. 并单一在数据库里写入对象格式的, 实际对象的保存里前面几个字节保存了对象编号的. 在封闭系统中, 这样做是很好的. 可是, memcached是个非封闭系统, 我无法控制不同对象的编号!
   召唤大人们给我个美丽的解决方案啊, 机器贵啊贵啊...节约一台是台.

我也想知道答案，楼上的研究出来后要做下贡献啊！

建议看一下代码，官方的memcached java client，set方法传入的value参数是一个object，他会默认使用serialize接口序列化这个类成，所以有上面说的class信息。

我的实现中set方法传入value的是一个byte[]，要求你自己序列化，我只管结果，所以你如果用ByteBuffer/IoBuffer/Externalizable就可以把对象转化成byte[]，根据自己的需求定格式，就可以没有class info。


另外我记得官方的客户端中，如果set传入的value参数是byte[]，应该不会序列化，直接使用byte[]，时间长了记不太清楚，楼上可以自己查一下代码。

14 楼 m8x6bmxb 2008-10-29  

sdh5724 写道

uniseraph 写道

sdh5724 写道

最近，我陷入一个郁闷。 就是JAVA的序列化问题。 当你向MEMCACHED直接写序列化的对象的时候， 一个对象完整的描述将会被写进memcached。 那么如果写1000W个对象给memcached, 对象描述将会被写无数次。 序列化描述大小往往远远大于对象的实际数据的， 因此， 我们的内存就被大量这些信息浪费了。 谁解决了这个问题？ 我在研究berkleydb java edition的解决方案。 这个问题对于内存节约使用是非常重要的。 我现在4台memcache机器吃了我20G内存， 再涨下去， 就要买机器了。 很不划算啊。

如果你放入的对象很多，对象类型不多，干脆将其转换成byte[]再写入memcached，用IoBuffer实现很简单。

你没有理解我的意思啊, 就是byte[] 也会有ClassInfo的啊. 我是做一个把所有CACHE种类接口统一化的项目.我无法预知用户要保存什么样的对象.  今天我研究了berkely DB java edition的代码, 发现他们是按照把存入对象的顺序, 把对象类型进行编号. 并单一在数据库里写入对象格式的, 实际对象的保存里前面几个字节保存了对象编号的. 在封闭系统中, 这样做是很好的. 可是, memcached是个非封闭系统, 我无法控制不同对象的编号!
   召唤大人们给我个美丽的解决方案啊, 机器贵啊贵啊...节约一台是台.

我也想知道答案，楼上的研究出来后要做下贡献啊！

13 楼 uniseraph 2008-10-29  

codeutil 写道

javabean实现Externalizable 接口，自己实现byte转换，就可以不依赖描述信息。
bdb无非也是用bind接口来干同样的事情而已。

sdh5724 写道最近，我陷入一个郁闷。 就是JAVA的序列化问题。
当你向MEMCACHED直接写序列化的对象的时候， 一个对象完整的描述将会被写进memcached。 那么如果写1000W个对象给memcached, 对象描述将会被写无数次。 序列化描述大小往往远远大于对象的实际数据的， 因此， 我们的内存就被大量这些信息浪费了。 谁解决了这个问题？ 我在研究berkleydb java edition的解决方案。 这个问题对于内存节约使用是非常重要的。 我现在4台memcache机器吃了我20G内存， 再涨下去， 就要买机器了。 很不划算啊。

正解。

12 楼 uniseraph 2008-10-29  

uniseraph 写道

dennis_zane 写道key和value的大小，网络状况也说明下嘛。纯粹的tps没有多大意义。
既然大家这么关心key/value大小，明天我给一个测试结果，今天实在没空了。

刚才试，当key长度为5，value长度为100的时候，速度和key为5，长度为5的基本一致。明天回公司，用服务器试试，应该还是能到60000。

11 楼 uniseraph 2008-10-29  

sdh5724 写道

uniseraph 写道sdh5724 写道
最近，我陷入一个郁闷。 就是JAVA的序列化问题。 当你向MEMCACHED直接写序列化的对象的时候， 一个对象完整的描述将会被写进memcached。 那么如果写1000W个对象给memcached, 对象描述将会被写无数次。 序列化描述大小往往远远大于对象的实际数据的， 因此， 我们的内存就被大量这些信息浪费了。 谁解决了这个问题？ 我在研究berkleydb java edition的解决方案。 这个问题对于内存节约使用是非常重要的。 我现在4台memcache机器吃了我20G内存， 再涨下去， 就要买机器了。 很不划算啊。


如果你放入的对象很多，对象类型不多，干脆将其转换成byte[]再写入memcached，用IoBuffer实现很简单。




你没有理解我的意思啊, 就是byte[] 也会有ClassInfo的啊. 我是做一个把所有CACHE种类接口统一化的项目.我无法预知用户要保存什么样的对象.  今天我研究了berkely DB java edition的代码, 发现他们是按照把存入对象的顺序, 把对象类型进行编号. 并单一在数据库里写入对象格式的, 实际对象的保存里前面几个字节保存了对象编号的. 在封闭系统中, 这样做是很好的. 可是, memcached是个非封闭系统, 我无法控制不同对象的编号!
   召唤大人们给我个美丽的解决方案啊, 机器贵啊贵啊...节约一台是台.

你看一下我的代码，byte[]不会产生ClassInfo，没有用对象序列化。

10 楼 codeutil 2008-10-29  

javabean实现Externalizable 接口，自己实现byte转换，就可以不依赖描述信息。
bdb无非也是用bind接口来干同样的事情而已。

sdh5724 写道

最近，我陷入一个郁闷。 就是JAVA的序列化问题。
当你向MEMCACHED直接写序列化的对象的时候， 一个对象完整的描述将会被写进memcached。 那么如果写1000W个对象给memcached, 对象描述将会被写无数次。 序列化描述大小往往远远大于对象的实际数据的， 因此， 我们的内存就被大量这些信息浪费了。 谁解决了这个问题？ 我在研究berkleydb java edition的解决方案。 这个问题对于内存节约使用是非常重要的。 我现在4台memcache机器吃了我20G内存， 再涨下去， 就要买机器了。 很不划算啊。

9 楼 sdh5724 2008-10-29  

uniseraph 写道

sdh5724 写道

最近，我陷入一个郁闷。 就是JAVA的序列化问题。 当你向MEMCACHED直接写序列化的对象的时候， 一个对象完整的描述将会被写进memcached。 那么如果写1000W个对象给memcached, 对象描述将会被写无数次。 序列化描述大小往往远远大于对象的实际数据的， 因此， 我们的内存就被大量这些信息浪费了。 谁解决了这个问题？ 我在研究berkleydb java edition的解决方案。 这个问题对于内存节约使用是非常重要的。 我现在4台memcache机器吃了我20G内存， 再涨下去， 就要买机器了。 很不划算啊。

如果你放入的对象很多，对象类型不多，干脆将其转换成byte[]再写入memcached，用IoBuffer实现很简单。

你没有理解我的意思啊, 就是byte[] 也会有ClassInfo的啊. 我是做一个把所有CACHE种类接口统一化的项目.我无法预知用户要保存什么样的对象.  今天我研究了berkely DB java edition的代码, 发现他们是按照把存入对象的顺序, 把对象类型进行编号. 并单一在数据库里写入对象格式的, 实际对象的保存里前面几个字节保存了对象编号的. 在封闭系统中, 这样做是很好的. 可是, memcached是个非封闭系统, 我无法控制不同对象的编号!
   召唤大人们给我个美丽的解决方案啊, 机器贵啊贵啊...节约一台是台.

8 楼 uniseraph 2008-10-28  

dennis_zane 写道

key和value的大小，网络状况也说明下嘛。纯粹的tps没有多大意义。

既然大家这么关心key/value大小，明天我给一个测试结果，今天实在没空了。

7 楼 uniseraph 2008-10-28  

sdh5724 写道

最近，我陷入一个郁闷。 就是JAVA的序列化问题。 当你向MEMCACHED直接写序列化的对象的时候， 一个对象完整的描述将会被写进memcached。 那么如果写1000W个对象给memcached, 对象描述将会被写无数次。 序列化描述大小往往远远大于对象的实际数据的， 因此， 我们的内存就被大量这些信息浪费了。 谁解决了这个问题？ 我在研究berkleydb java edition的解决方案。 这个问题对于内存节约使用是非常重要的。 我现在4台memcache机器吃了我20G内存， 再涨下去， 就要买机器了。 很不划算啊。

如果你放入的对象很多，对象类型不多，干脆将其转换成byte[]再写入memcached，用IoBuffer实现很简单。

6 楼 sdh5724 2008-10-28  

最近，我陷入一个郁闷。 就是JAVA的序列化问题。
当你向MEMCACHED直接写序列化的对象的时候， 一个对象完整的描述将会被写进memcached。 那么如果写1000W个对象给memcached, 对象描述将会被写无数次。 序列化描述大小往往远远大于对象的实际数据的， 因此， 我们的内存就被大量这些信息浪费了。 谁解决了这个问题？ 我在研究berkleydb java edition的解决方案。 这个问题对于内存节约使用是非常重要的。 我现在4台memcache机器吃了我20G内存， 再涨下去， 就要买机器了。 很不划算啊。