I had tested the following key-value store for set() and get()
- MemcacheDB, use memcached client protocol.
- Tokyo Tyrant (Tokyo Cabinet), use memcached client protocol
- Redis, use JRedis Java client
1. Test environment
1.1 Hardware/OS
2 Linux boxes in a LAN, 1 server and 1 test client
Linux Centos 5.2 64bit
Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (L2 cache: 6M), Quad-Core * 2
8G memory
SCSI disk (standalone disk, no other access)
1.2 Software version
db-4.7.25.tar.gz
libevent-1.4.11-stable.tar.gz
memcached-1.2.8.tar.gz
memcachedb-1.2.1-beta.tar.gz
redis-0.900_2.tar.gz
tokyocabinet-1.4.9.tar.gz
tokyotyrant-1.1.9.tar.gz
1.3 Configuration
Memcachedb startup parameter
Test 100 bytes
./memcachedb -H /data5/kvtest/bdb/data -d -p 11212 -m 2048 -N -L 8192
(Update: As mentioned by Steve, the 100-byte-test missed the -N paramter, so I added it and updated the data)
Test 20k bytes
./memcachedb -H /data5/kvtest/mcdb/data -d -p 11212 -b 21000 -N -m 2048
Tokyo Tyrant (Tokyo Cabinet) configuration
Use default Tokyo Tyrant sbin/ttservctl
use .tch database, hashtable database
ulimsiz=”256m”
sid=1
dbname=”$basedir/casket.tch#bnum=50000000″ # default 1M is not enough!
maxcon=”65536″
retval=0
Redis configuration
timeout 300
save 900 1
save 300 10
save 60 10000
# no maxmemory settings
1.4 Test client
Client in Java, JDK1.6.0, 16 threads
Use Memcached client java_memcached-release_2.0.1.jar
JRedis client for Redis test, another JDBC-Redis has poor performance.
2. Small data size test result
Test 1, 1-5,000,000 as key, 100 bytes string value, do set, then get test, all get test has result.
Request per second(mean)
| Store | Write | Read |
| Memcached | 55,989 | 50,974 |
| Memcachedb | 25,583 | 35,260 |
| Tokyo Tyrant | 42,988 | 46,238 |
| Redis | 85,765 | 71,708 |
Server Load Average
| Store | Write | Read |
| Memcached | 1.80, 1.53, 0.87 | 1.17, 1.16, 0.83 |
| MemcacheDB | 1.44, 0.93, 0.64 | 4.35, 1.94, 1.05 |
| Tokyo Tyrant | 3.70, 1.71, 1.14 | 2.98, 1.81, 1.26 |
| Redis | 1.06, 0.32, 0.18 | 1.56, 1.00, 0.54 |
3. Larger data size test result
Test 2, 1-500,000 as key, 20k bytes string value, do set, then get test, all get test has result.
Request per second(mean)
(Aug 13 Update: fixed a bug on get() that read non-exist key)
| Store | Write | Read |
| Memcachedb | 357 | 327 |
| Tokyo Tyrant | 3,501 | 257 |
| Redis | 1,542 | 957 |
4. Some notes about the test
When test Redis server, the memory goes up steadily, consumed all 8G and then use swap(and write speed slow down), after all memory and swap space is used, the client will get exceptions. So use Redis in a productive environment should limit to a small data size. It is another cache solution rather than a persistent storage. So compare Redis together with MemcacheDB/TC may not fair because Redis actually does not save data to disk during the test.
Tokyo cabinet and memcachedb are very stable during heavy load, use very little memory in set test and less than physical memory in get test.
MemcacheDB peformance is poor for write large data size(20k).
The call response time was not monitored in this test.
[…] 题外话说完，最近又研究了Redis。去年曾做过一个MemcacheDB, Tokyo Tyrant, Redis performance test， 到目前为止，这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的key value存储产品的诱惑，从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用 HBase(2))，当再回头再去看Redis，发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人，国内前十大网站 的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外，业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大 家探讨。 […]
[…] 题外话说完，最近又研究了Redis。去年曾做过一个MemcacheDB, Tokyo Tyrant, Redis performance test，到目前为止，这个benchmark结果依然有效。这1年我们经历了很多眼花缭乱的key value存储产品的诱惑，从Cassandra的淡出(Twitter暂停在主业务使用)到HBase的兴起(Facebook新的邮箱业务选用HBase(2))，当再回头再去看Redis，发现这个只有1万多行源代码的程序充满了神奇及大量未经挖掘的特性。Redis性能惊人，国内前十大网站的子产品估计用1台Redis就可以满足存储及Cache的需求。除了性能印象之外，业界其实普遍对Redis的认识存在一定误区。本文提出一些观点供大家探讨。 […]
ho
man
When tes
[…] 这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 […]
[…] article about key–value databases。 仅供参考，older software list 仅供参考，speed comparison of MemcacheDB, Redis and Tokyo Cabinet Tyrant […]
[…] MemcacheDB, Tokyo Tyrant, Redis performance test: [http://timyang.net/data/mcdb-tt-redis/] […]
Hi, this weekend is good in favor of me, as this occasion i am reading this wonderful informative paragraph here at my home.
redis有没有象memcached这样的过期时间设置
Tokyo cabinet and memcachedb are very stable during heavy load, use very little memory in set test and less than physical memory in get test.
compare Redis together with MemcacheDB/TC may not fair because Redis actually does not save data to disk during the test.
a very detailed and meticulous lesson, it really has a lot of values, I will learn a lot thanks
Thanks for great article!
Nice
Nice article
I will follow it to know more info and expand my data, and I think everyone should know it.
Oh, great, your article provided me with useful information and a fresh perspective on the subject.