permalink: /overview/benchmark/

测试环境

机器配置:

  • CPU:Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz (24 cores)
  • 内存​:128GB
  • 存储:480G RAID0 SSD *8
  • 网卡:10Gb

集群配置:

  • 节点数:5个replica server节点
  • 测试表的Partition数:64个

测试工具:

  • YCSB (使用Pegasus Java Client)
  • 读写请求的数据分布特征:zipfian,可以理解为遵守80/20原则的数据分布,即80%的访问都集中在20%的内容上。

备注:

  • 运行时长单位:小时。
  • QPS单位:条/秒。
  • 延迟单位:微秒。

测试结果

1.12.3

  • 延迟单位: 微秒
  • pegasu-client: 1.11.10-thrift-0.11.0-inlined-release
  • 客户端节点数: 3

单条数据大小:320B

测试caseRW RatioR-QPSR-AVG-LatR-P99-LatW-QPSW-AVG-LatW-P99-Lat
读写同时: 3客户端*15线程0:1410687283439
读写同时: 3客户端*15线程1:316011242686480368514027
读写同时: 3客户端*30线程30:127981829587393267203355

单条数据大小:1KB

测试caseRW RatioR-QPSR-AVG-LatR-P99-LatW-QPSW-AVG-LatW-P99-Lat
读写同时: 3客户端*15线程0:14073211024216
读写同时: 3客户端*15线程1:31435547628553854710164135
读写同时: 3客户端*20线程3:1874803684170291599404170
读写同时: 3客户端*50线程1:03122444791178

1.12.2

  • 延迟单位: 微秒
  • pegasu-client: 1.11.10-thrift-0.11.0-inlined-release
  • 客户端节点数: 3
  • 单条数据大小:320B
测试caseRW RatioR-QPSR-AVG-LatR-P99-LatW-QPSW-AVG-LatW-P99-Lat
读写同时: 3客户端*15线程0:1404397392995
读写同时: 3客户端*15线程1:316022309759480788303995
读写同时: 3客户端*30线程30:124439234665281377312995

1.11.6(multi_get/batch_set)

特别注意:测试环境和参数以此为准

  • 测试case:读使用multi_get,写使用batch_set,1QPS的batch_set等于3QPS的set操作
  • 数据大小:单条数据3KB,sort_key数量为3
  • 测试表的Partition数:128个
  • rocksdb_block_cache_capacity = 40G
  • pegasu-client = 1.11.7-thrift-0.11.0-inlined-release

| 测试Case | 读写比 | 运行时长 | Max缓存命中率 | 读QPS | 读Avg延迟 | 读P99延迟 | 读P999延迟 | 写QPS | 写Avg延迟 | 写P99延迟 | 写P999延迟 | | -------------- | ------ | -------- | ------------- | ----- | --------- | --------- | ---------- | ----- | --------- | --------- | | 3客户端15线程 | ​20:1 | 1h | 10% | 150K | 263 | 808 | 12615 | 8k | 1474 | 7071 | 26342 | | ​3客户端7线程 | ​20:1 | 2h | 17% | 75K | 226 | 641 | 5331 | 4K | 1017 | 4583 | 14983 |

1.11.1

单条数据大小:20KB

测试时间:2018/11/9

2备份
测试Case读写比运行时长读QPS读Avg延迟读P99延迟写QPS写Avg延迟写P99延迟
(1)数据加载: 3客户端*10线程0:10.98---8439355732223
(2)​读写同时: 3客户端*15线程​1:30.6631594428344959472325125071
​(3)读写同时: 3客户端*30线程​30:11.2564358133013975214516996467
(4)数据只读: 6客户端*100线程1:0​​0.9130491327412167---
3备份
测试Case读写比运行时长读QPS读Avg延迟读P99延迟写QPS写Avg延迟写P99延迟
(1)数据加载: 3客户端*10线程0:11.40---5919506340639
(2)​读写同时: 3客户端*15线程​1:31.1118766927446395632561276095
​(3)读写同时: 3客户端*30线程​30:11.63493411751216151644193511159
(4)数据只读: 6客户端*100线程1:0​​0.9125456392315679---

单条数据大小:10KB

测试时间:2018/11/5

2备份
测试Case读写比运行时长读QPS读Avg延迟读P99延迟写QPS写Avg延迟写P99延迟
(1)数据加载: 3客户端*10线程0:10.78---14181211015468
(2)​读写同时: 3客户端*15线程​1:30.52402452094124712069178014495
​(3)读写同时: 3客户端*30线程​30:10.761058418169613352711074155
(4)数据只读: 6客户端*100线程1:0​​​1.0416215018686733---
3备份
测试Case读写比运行时长读QPS读Avg延迟读P99延迟写QPS写Avg延迟写P99延迟
(1)数据加载: 3客户端*10线程0:11.16---9603311520468
(2)​读写同时: 3客户端*15线程​1:30.6930435657387839126314027956
​(3)读写同时: 3客户端*30线程​30:10.899013593713324300211854816
(4)数据只读: 6客户端*100线程1:0​1.0815486919457757---

RocsDB配置:

    rocksdb_abnormal_get_time_threshold_ns = 10000000
    rocksdb_abnormal_get_size_threshold = 1000000
    rocksdb_abnormal_multi_get_time_threshold_ns = 100000000
    rocksdb_abnormal_multi_get_size_threshold = 10000000
    rocksdb_abnormal_multi_get_iterate_count_threshold = 1000

    rocksdb_write_buffer_size = 67108864
    rocksdb_max_write_buffer_number = 6
    rocksdb_max_background_flushes = 4
    rocksdb_max_background_compactions = 12
    rocksdb_num_levels = 6
    rocksdb_target_file_size_base = 67108864
    rocksdb_target_file_size_multiplier = 1
    rocksdb_max_bytes_for_level_base = 671088640
    rocksdb_max_bytes_for_level_multiplier = 10
    rocksdb_level0_file_num_compaction_trigger = 4
    rocksdb_level0_slowdown_writes_trigger = 30
    rocksdb_level0_stop_writes_trigger = 60
    rocksdb_disable_table_block_cache = false
    rocksdb_compression_type = snappy none

1.11.0

  • 单条数据大小:320字节
  • 测试时间:2018/07/27
测试Case读写比运行时长读QPS读Avg延迟读P99延迟写QPS写Avg延迟写P99延迟
(1)数据加载: 3客户端*10线程0:11.89---440396793346
(2)​读写同时: 3客户端*15线程​1:31.2416690311892500767914396
​(3)读写同时: 3客户端*30线程​30:11.04311633264511103886192468
(4)数据只读: 6客户端*100线程1:0​​0.17​978884623​1671---
(5)数据只读: 12客户端*100线程1:0​​0.28​11943941003​2933---

不同参数下的性能

如无特殊说明:

  • 延迟单位:微妙
  • 单条数据大小:1KB
  • 客户端节点数:3,版本号:1.11.10-thrift-0.11.0-inlined-release
  • 服务端节点数:5,版本号:1.12.3,表分片数:64,开启rocksdb限速:max_rate=500MB, auto_tune=true

客户端线程数

该项测试旨在观察在默认配置下(注意:未开启RocksDB限速),不同线程(仅读和仅写)对QPS和延迟的影响。

5-node-write

5-node-read

由上图可以看到,在该测试场景下,写最大QPS≈43K,读最大QPS≈370K,你也可以根据QPS的大小合理估算对应的延迟。

RocksDB限速

Pegasus底层采用RocksDB做存储引擎,当数据写入增多,会触发compaction操作,占用较多磁盘IO,出现较多的毛刺现象。该项测试展示了开启RocksDB的限速后,可以降低compaction负载,从而显著的降低毛刺现象。

下图分别展示了无限速、500MB限速、500MB限速同时开启auto-tune功能,三种场景的IO使用率和写P99延迟(注意:测试场景为:3client*20thread,QPS≈44K):

磁盘IO占用: io-no-limit io-limit-500MB io-limit-500MB-auto

P99延迟: no-limit-set 500-limit-set 500-limit-auto-set

可以发现,磁盘IO使用率被降低,相应的写延迟的毛刺现象也被大大缓解。

我们从YCSB的测试结果: limit 也可以看到:

  • 开启限速、开启限速并开启auto-tune后,QPS吞吐分别约提升了5%,20%
  • 开启限速后,仅对极端情况下的延迟(P999/P9999)有显著改善作用,对于大部分请求来说,改善并不明显

但是需要注意的是:

auto-tune功能在单条数据较大的场景下可能会引发write stall(在我们的测试中,当单条value=10KB,QPS=10K时,发生write stall,关闭Auto-Tune后不会产生write stall),所以请合理评估是否开启auto-tune

服务端机器数

该项测试旨在观察,不同机器数量对读写性能(只读和只写场景)的影响。 node-write

node-read

由图中可以看到

  • 扩容对写性能的提升要优于读性能的提升
  • 扩容带来的性能提升并不是线性增加的

你可以根据该项测试合理估计不同机器下所能承载的请求负载

表分片数

该项测试旨在观察,表的不同分片对性能的影响。测试场景为:

仅读:3client*50thread

仅写:3client*40thread

partition

由图中可以看到,增加分片可以提高读性能,但是降低了写性能,所以请合理评估你的业务需求。除此之外,若分片数过小,可能会导致单分片过大,磁盘分布不均的问题,在实际的线上业务中,如无特别需求,我们建议单分片维持在10GB以内是合理的