1.4 Test client

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.