Skip to content

Commit

Permalink
Update Readme (OpenAtomFoundation#701)
Browse files Browse the repository at this point in the history
Compact performance test into a link.
whoiami committed Aug 6, 2019
1 parent 9f89d27 commit e3552b4
Showing 1 changed file with 2 additions and 215 deletions.
217 changes: 2 additions & 215 deletions README.md
Original file line number Diff line number Diff line change
@@ -94,224 +94,11 @@ make
./output/bin/pika -c ./conf/pika.conf
```

## Performance (provided by [deep011](https://github.com/deep011))
## Performance

### test environment
More details on [Performance](https://github.com/Qihoo360/pika/wiki/3.2.x-Performance).

**CPU module**:Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz

**CPU threads**:56

**MEMORY**:256G

**DISK**:3T flash

**NETWORK**:10GBase-T/Full * 2

**OS**:centos 6.6

### benchmark tools

[**vire-benchmark**](https://deep011.github.io/vire-benchmark)

### Test 1

#### Purpose

With different number of pika worker threads, we test pika's max QPS.

#### Condition

pika db_size : 800G

value : 128bytes

Threads are not bound to CPU cores.

#### Result

Description : Horizontal axis is the number of worker threads; Vertical axis is the QPS. The value size is 128bytes. set3/get7 means 30% set and 70% get.

<img src="https://deep011.github.io/public/images/pika_benchmark/pika_threads_test.png" height = "60%" width = "60%" alt="1"/>

#### Conclusion

The best pika worker threads number is 20-24.

### Test 2

#### Purpose

With the optimal worker threads number, we test pika's round-trip time.

#### Condition

**pika db_size**:800G

**value**:128bytes

#### Result

```c
====== GET ======
10000000 requests completed in 23.10 seconds
200 parallel clients
3 bytes payload
keep alive: 1
99.89% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 3 milliseconds
100.00% <= 5 milliseconds
100.00% <= 6 milliseconds
100.00% <= 7 milliseconds
100.00% <= 7 milliseconds
432862.97 requests per second
```

```c
====== SET ======
10000000 requests completed in 36.15 seconds
200 parallel clients
3 bytes payload
keep alive: 1
91.97% <= 1 milliseconds
99.98% <= 2 milliseconds
99.98% <= 3 milliseconds
99.98% <= 4 milliseconds
99.98% <= 5 milliseconds
99.98% <= 6 milliseconds
99.98% <= 7 milliseconds
99.98% <= 9 milliseconds
99.98% <= 10 milliseconds
99.98% <= 11 milliseconds
99.98% <= 12 milliseconds
99.98% <= 13 milliseconds
99.98% <= 16 milliseconds
99.98% <= 18 milliseconds
99.99% <= 19 milliseconds
99.99% <= 23 milliseconds
99.99% <= 24 milliseconds
99.99% <= 25 milliseconds
99.99% <= 27 milliseconds
99.99% <= 28 milliseconds
99.99% <= 34 milliseconds
99.99% <= 37 milliseconds
99.99% <= 39 milliseconds
99.99% <= 40 milliseconds
99.99% <= 46 milliseconds
99.99% <= 48 milliseconds
99.99% <= 49 milliseconds
99.99% <= 50 milliseconds
99.99% <= 51 milliseconds
99.99% <= 52 milliseconds
99.99% <= 61 milliseconds
99.99% <= 63 milliseconds
99.99% <= 72 milliseconds
99.99% <= 73 milliseconds
99.99% <= 74 milliseconds
99.99% <= 76 milliseconds
99.99% <= 83 milliseconds
99.99% <= 84 milliseconds
99.99% <= 88 milliseconds
99.99% <= 89 milliseconds
99.99% <= 133 milliseconds
99.99% <= 134 milliseconds
99.99% <= 146 milliseconds
99.99% <= 147 milliseconds
100.00% <= 203 milliseconds
100.00% <= 204 milliseconds
100.00% <= 208 milliseconds
100.00% <= 217 milliseconds
100.00% <= 218 milliseconds
100.00% <= 219 milliseconds
100.00% <= 220 milliseconds
100.00% <= 229 milliseconds
100.00% <= 229 milliseconds
276617.50 requests per second
```

#### Conclusion

Both the 99.9% get/set RTT are below 2ms.

### Test 3

#### Purpose

With the optimal worker threads number, we test the max qps of different commands.

#### Condition

**pika worker threads**:20

**key count**:10000

**field count**:100(except list)

**value**:128bytes

**commands execute times**:10000000(except lrange)

#### Result

```c
PING_INLINE: 548606.50 requests per second
PING_BULK: 544573.31 requests per second
SET: 231830.31 requests per second
GET: 512163.91 requests per second
INCR: 230861.56 requests per second
MSET (10 keys): 94991.12 requests per second
LPUSH: 196093.81 requests per second
RPUSH: 195186.69 requests per second
LPOP: 131156.14 requests per second
RPOP: 152292.77 requests per second
LPUSH (needed to benchmark LRANGE): 196734.20 requests per second
LRANGE_10 (first 10 elements): 334448.16 requests per second
LRANGE_100 (first 100 elements): 50705.12 requests per second
LRANGE_300 (first 300 elements): 16745.16 requests per second
LRANGE_450 (first 450 elements): 6787.94 requests per second
LRANGE_600 (first 600 elements): 3170.38 requests per second
SADD: 160885.52 requests per second
SPOP: 128920.80 requests per second
HSET: 180209.41 requests per second
HINCRBY: 153364.81 requests per second
HINCRBYFLOAT: 141095.47 requests per second
HGET: 506791.00 requests per second
HMSET (10 fields): 27777.31 requests per second
HMGET (10 fields): 38998.52 requests per second
HGETALL: 109059.58 requests per second
ZADD: 120583.62 requests per second
ZREM: 161689.33 requests per second
PFADD: 6153.47 requests per second
PFCOUNT: 28312.57 requests per second
PFADD (needed to benchmark PFMERGE): 6166.37 requests per second
PFMERGE: 6007.09 requests per second
```
### Test 4
#### Purpose
Compare the pika max qps with the redis.
#### Condition
**pika worker threads**:20
**key count**:10000
**field count**:100(except list)
**value**:128bytes
**commands execute times**:10000000(except lrange)
**Redis version**:3.2.0
#### Result
<img src="https://deep011.github.io/public/images/pika_benchmark/pika_vs_redis_qps.png" height = "60%" width = "60%" alt="1"/>
## Documents

1. [Wiki](https://github.com/Qihoo360/pika/wiki)

0 comments on commit e3552b4

Please sign in to comment.