Redis VS memcached Stress test Report

A Test Background and objectives

Understand the response time and throughput of Redis and memcached under high concurrency conditions, as well as the pressure on the server (including CPU, IO, network), and review the current memcached storage timeline response time, throughput, Load conditions, and advantages of using Redis storage timeline

Two Test environment

1. Server

buzz090, Blade server

2. Operating system

CentOS Release 5.5 system, Kernel Edition: Linux version 2.6.18-194.el5

3. Hardware

Intel (R) Xeon (r) CPU E5640 @ 2.67GHz 16cpu;48g memory; Gigabit NIC

4. Software:

Uredis version: 2.6.0-RC5 (2.5.11), mainly in order to test the Lua script function later, deploy three nodes, each node open 2G memory, a total of 6 g. Open aof, strategy every second, close RDB, open LRU, policy: ALLKEYS-LRU

Umemcached version: 1.4.5. Deploy three nodes, each node open 2G memory, a total of 6G

5. Client

buzz097, hardware environment, operating system and buzz090 consistent.

The client and server use intranet interconnection.

Three Testing tools

1.Redis Client

Jedis, version number 2.1.0. The pool settings are used by default and are not tuned. Timeout time is 5s

2.Memcached Client

xmemcached, version number 1.3.5, use the consistent hash, use Binarycommandfactory, use failure mode, but not configure the standby (-_-). Timeout Time 5s

3. Pressure testing tools

The pressure test framework written by the Waves (strike)

Four Test method

1. Test methods

Respectively, 100, 200, 500, 1000 concurrent thread pressure test Redis, memcached method, the running time is 20-60 minutes, each round of pressure test sampling 3,000 times, the pressure test to observe the following parameters:

U response time for single operation

Response time (throughput) for u3000 operations

UCPU situation

U Network Rx, TX

Uio

2. Methods of stress testing

Redis:set, Zadd, Evalsha

Memcached:set, (gets, CAS combination of operations)

3. Some notes

A small number of tests were done for the read operation, and the performance was similar to the set operation and no separate test report was made. The important point of read operation is: In Redis, for a large sorted set, you must specify a range when using Zrange, otherwise you will get a lot of errors

Five Test Cases:

Comparison of the set method of 1.Redis and the set method of memcached

U test method: Using the pseudo random number generated by Java to redis the set operation, the memcached do set operation.

U Test Results:

Redis:

Under 100 threads, the single operation time is 0-1ms, the time running 3,000 times is 80-95ms, that is, the throughput is 32000-38000;CPU idle 96%;io wr_sec/s is 4000; network rxkb/s:3000,txkb/ S is 1500-2000

Under 200 threads, the single operation time is 0-1ms, the time running 3,000 times is 87-105ms, that is, the throughput is 28500-34500;CPU idle 96%;io wr_sec/s is 4000; network rxkb/s:3000,txkb/ S is 1500-2000

Under 500 threads, the single operation time is 0-1ms, the time running 3,000 times is 95-110ms, that is, the throughput is 27000-31500;CPU idle 96%;io wr_sec/s is 4000; network rxkb/s:3000,txkb/ S is 1500-2000

Under 1000 threads, the single operation time is 0-1ms, the time running 3,000 times is 97-120ms, that is, the throughput is 25000-30000;CPU idle 96%;io wr_sec/s is 4000; network rxkb/s:3000,txkb/ S is 1500-2000

Memcached:

100, 200, 500 threads, the basic difference is not small: a single operation time, the time to run 3,000 times for 65-85ms, that is, throughput for 35000-46000;CPU idle 97%;io wr_sec/s to 260-350; network rxkb/s:3000, TXKB/S is 3000

Summary of U

Memcached has better performance than Redis in writing small data, not only has high throughput, but also has obvious advantages in server load and IO.

After the Redis closed aof, the performance probably rose by 5%-10%, which is worth using.

Redis can't feel the loss of performance when LRU.

Comparison between the Zadd method of 2.Redis and the combination of gets CAs methods for memcached:

U background: Current microblog timeline uses memcached gets CAS combination to achieve optimistic locking and ensure timeline consistency.

U test method: Build 37 sorted set for Redis, 3,700 key for memcached, concurrent write. of which Redis