性能测试
测试环境
机器配置:
- 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
测试case | RW Ratio | R-QPS | R-AVG-Lat | R-P99-Lat | W-QPS | W-AVG-Lat | W-P99-Lat |
---|---|---|---|---|---|---|---|
读写同时: 3客户端*15线程 | 0:1 | 41068 | 728 | 3439 | |||
读写同时: 3客户端*15线程 | 1:3 | 16011 | 242 | 686 | 48036 | 851 | 4027 |
读写同时: 3客户端*30线程 | 30:1 | 279818 | 295 | 873 | 9326 | 720 | 3355 |
单条数据大小:1KB
测试case | RW Ratio | R-QPS | R-AVG-Lat | R-P99-Lat | W-QPS | W-AVG-Lat | W-P99-Lat |
---|---|---|---|---|---|---|---|
读写同时: 3客户端*15线程 | 0:1 | 40732 | 1102 | 4216 | |||
读写同时: 3客户端*15线程 | 1:3 | 14355 | 476 | 2855 | 38547 | 1016 | 4135 |
读写同时: 3客户端*20线程 | 3:1 | 87480 | 368 | 4170 | 29159 | 940 | 4170 |
读写同时: 3客户端*50线程 | 1:0 | 312244 | 479 | 1178 |
1.12.2
- 延迟单位: 微秒
- pegasu-client: 1.11.10-thrift-0.11.0-inlined-release
- 客户端节点数: 3
- 单条数据大小:320B
测试case | RW Ratio | R-QPS | R-AVG-Lat | R-P99-Lat | W-QPS | W-AVG-Lat | W-P99-Lat |
---|---|---|---|---|---|---|---|
读写同时: 3客户端*15线程 | 0:1 | 40439 | 739 | 2995 | |||
读写同时: 3客户端*15线程 | 1:3 | 16022 | 309 | 759 | 48078 | 830 | 3995 |
读写同时: 3客户端*30线程 | 30:1 | 244392 | 346 | 652 | 8137 | 731 | 2995 |
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:1 | 0.98 | - | - | - | 8439 | 3557 | 32223 |
(2)读写同时: 3客户端*15线程 | 1:3 | 0.66 | 3159 | 4428 | 34495 | 9472 | 3251 | 25071 |
(3)读写同时: 3客户端*30线程 | 30:1 | 1.25 | 64358 | 1330 | 13975 | 2145 | 1699 | 6467 |
(4)数据只读: 6客户端*100线程 | 1:0 | 0.91 | 30491 | 3274 | 12167 | - | - | - |
3备份
测试Case | 读写比 | 运行时长 | 读QPS | 读Avg延迟 | 读P99延迟 | 写QPS | 写Avg延迟 | 写P99延迟 |
---|---|---|---|---|---|---|---|---|
(1)数据加载: 3客户端*10线程 | 0:1 | 1.40 | - | - | - | 5919 | 5063 | 40639 |
(2)读写同时: 3客户端*15线程 | 1:3 | 1.11 | 1876 | 6927 | 44639 | 5632 | 5612 | 76095 |
(3)读写同时: 3客户端*30线程 | 30:1 | 1.63 | 49341 | 1751 | 21615 | 1644 | 1935 | 11159 |
(4)数据只读: 6客户端*100线程 | 1:0 | 0.91 | 25456 | 3923 | 15679 | - | - | - |
单条数据大小:10KB
测试时间:2018/11/5
2备份
测试Case | 读写比 | 运行时长 | 读QPS | 读Avg延迟 | 读P99延迟 | 写QPS | 写Avg延迟 | 写P99延迟 |
---|---|---|---|---|---|---|---|---|
(1)数据加载: 3客户端*10线程 | 0:1 | 0.78 | - | - | - | 14181 | 2110 | 15468 |
(2)读写同时: 3客户端*15线程 | 1:3 | 0.52 | 4024 | 5209 | 41247 | 12069 | 1780 | 14495 |
(3)读写同时: 3客户端*30线程 | 30:1 | 0.76 | 105841 | 816 | 9613 | 3527 | 1107 | 4155 |
(4)数据只读: 6客户端*100线程 | 1:0 | 1.04 | 162150 | 1868 | 6733 | - | - | - |
3备份
测试Case | 读写比 | 运行时长 | 读QPS | 读Avg延迟 | 读P99延迟 | 写QPS | 写Avg延迟 | 写P99延迟 |
---|---|---|---|---|---|---|---|---|
(1)数据加载: 3客户端*10线程 | 0:1 | 1.16 | - | - | - | 9603 | 3115 | 20468 |
(2)读写同时: 3客户端*15线程 | 1:3 | 0.69 | 3043 | 5657 | 38783 | 9126 | 3140 | 27956 |
(3)读写同时: 3客户端*30线程 | 30:1 | 0.89 | 90135 | 937 | 13324 | 3002 | 1185 | 4816 |
(4)数据只读: 6客户端*100线程 | 1:0 | 1.08 | 154869 | 1945 | 7757 | - | - | - |
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:1 | 1.89 | - | - | - | 44039 | 679 | 3346 |
(2)读写同时: 3客户端*15线程 | 1:3 | 1.24 | 16690 | 311 | 892 | 50076 | 791 | 4396 |
(3)读写同时: 3客户端*30线程 | 30:1 | 1.04 | 311633 | 264 | 511 | 10388 | 619 | 2468 |
(4)数据只读: 6客户端*100线程 | 1:0 | 0.17 | 978884 | 623 | 1671 | - | - | - |
(5)数据只读: 12客户端*100线程 | 1:0 | 0.28 | 1194394 | 1003 | 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和延迟的影响。
由上图可以看到,在该测试场景下,写最大QPS≈43K,读最大QPS≈370K,你也可以根据QPS的大小合理估算对应的延迟。
RocksDB限速
Pegasus底层采用RocksDB做存储引擎,当数据写入增多,会触发compaction操作,占用较多磁盘IO,出现较多的毛刺现象。该项测试展示了开启RocksDB的限速后,可以降低compaction负载,从而显著的降低毛刺现象。
下图分别展示了无限速、500MB限速、500MB限速同时开启auto-tune功能,三种场景的IO使用率和写P99延迟(注意:测试场景为:3client*20thread,QPS≈44K):
磁盘IO占用:
P99延迟:
可以发现,磁盘IO使用率被降低,相应的写延迟的毛刺现象也被大大缓解。
我们从YCSB的测试结果:
也可以看到:
- 开启限速、开启限速并开启auto-tune后,QPS吞吐分别约提升了5%,20%
- 开启限速后,仅对极端情况下的延迟(P999/P9999)有显著改善作用,对于大部分请求来说,改善并不明显
但是需要注意的是:
auto-tune功能在单条数据较大的场景下可能会引发write stall(在我们的测试中,当单条value=10KB,QPS=10K时,发生write stall,关闭Auto-Tune后不会产生write stall),所以请合理评估是否开启auto-tune
服务端机器数
该项测试旨在观察,不同机器数量对读写性能(只读和只写场景)的影响。
由图中可以看到
- 扩容对写性能的提升要优于读性能的提升
- 扩容带来的性能提升并不是线性增加的
你可以根据该项测试合理估计不同机器下所能承载的请求负载
表分片数
该项测试旨在观察,表的不同分片对性能的影响。测试场景为:
仅读:3client*50thread
仅写:3client*40thread
由图中可以看到,增加分片可以提高读性能,但是降低了写性能,所以请合理评估你的业务需求。除此之外,若分片数过小,可能会导致单分片过大,磁盘分布不均的问题,在实际的线上业务中,如无特别需求,我们建议单分片维持在10GB以内是合理的