令人振奋的结果: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

访问密码是多少

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

你用匿名访问http://commons-client.googlecode.com/svn/trunk好了，不用密码。

我也想知道确切的key,value大小。环境不同效果截然会不一样

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

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

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

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

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