performance benchmark : memcached vs Kyoto Tycoon
kt:
http://fallabs.com/kyototycoon/
说明:
1) 客户端服务端都是8核,千兆网卡
2) 表格横向是value的数据大小
3) 表格的值是每秒操作数
4) KC创建的是hash库
100B | 1KB | 10KB | 100KB | 1MB | |
KT写 | 35599 | 35075 | 34518 | 33189 | 30562 |
KT读 | 37939 | 40209 | 38095 | 38197 | 40518 |
KT删 | 39968 | 39541 | 39200 | 37091 | 37664 |
MEMCACHE写 | 28735 | 29394 | 28977 | 27382 | 27824 |
MEMCACHE读 | 30515 | 30931 | 30057 | 28968 | 30721 |
MEMCACHE删 | 32362 | 32278 | 31715 | 30609 | 32175 |
补充说明:
1) kt启用GC,开启memcache协议扩展,使用的是一套客户端。
2) 客户端测试的时候使用并行库,多线程操作。
3) value都是string,不涉及序列化反序列化操作
结论:
咋KT的性能比memcached还牛呢?而且,数据移除之后马上释放磁盘,不像Mongodb和MSSQL一样会占着文件,除非repair才会收缩。
但是,数据量多了情况会不会发生变化呢?(以下测试使用三台机器,也就是一台机器保存三分之一的数据)
我们来看下KT在每多100万数据量的时候,读写效率的情况,表格的值同样是每秒操作数:
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | |
KT写 | 21010 | 11660 | 6888 | 4409 | 3311 | 2637 | 2387 | 1855 | 1803 | 1590 |
KT读 | 26063 | 25241 | 26139 | 25931 | 25810 | 26062 | 26106 | 26055 | 25465 | 3208 |
结论:
读基本没有下降,写大幅下降,总数据量在千万(由于是三台机器,所以最多的一台机器数据量也只有500万)的时候相比空数据的时候只有10%的写入速度,不如Mongodb,而读取速度相比Mongodb占优。
最后一次读取效率大幅降低,此时之前保存的数据已经过时,考虑是否GC回收过期数据会影响读取效率?
最后补充一点吧:KT默认情况下memcache plugin没有支持gets,如果要批量获取的话可以直接使用get命令。