Klustron（原KunlunBase） 1.1 性能对比测试报告

1. 测试场景及工具

在 Klustron 1.1 版本发布之后，我们针对新版本与其他竞品进行了性能对比测试。测试模型采用 TPCC。其中与 TiDB 的对比采用 go-tpc，该工具是 TiDB 提供的符合 TPCC 标准的压测工具。与 OceanBase 的对比测试中，采用了 benchmarkSQL 工具，该工具是 TPCC 的开源实现，该工具也是 OceanBase 官方推荐的压测工具。

2. 物理资源及部署配置

本次测试机器资源为阿里云 ECS，其中资源配置如下图标所示

资源名	资源规格	规格详情
CLIENT	ecs.c5.4xlarge	VCPU:2 MEM:4
META	ecs.g5.2xlarge	VCPU:8 MEM:32
STORAGE001	ecs.r6e.8xlarge	VCPU:32 MEM:256
STORAGE002	ecs.r6e.8xlarge	VCPU:32 MEM:256
STORAGE003	ecs.r6e.8xlarge	VCPU:32 MEM:256
STORAGE004	ecs.r6e.8xlarge	VCPU:32 MEM:256
STORAGE005	ecs.r6e.8xlarge	VCPU:32 MEM:256
STORAGE006	ecs.r6e.8xlarge	VCPU:32 MEM:256

上表所列出来的所有的物理设备，都是在同一个可用区，因而内网带宽可以理解为没有瓶颈。同事每个 storage 设备，都会挂载一个200GB 的 ESSD 云盘作为主要的外存，所有的日志及数据都会落在该磁盘上。

2.1 Klustron 部署拓扑及配置

其中 Klustron 的部署模式如下:

组件/资源名	meta	storage1	storage2	storage3	storage4	storage5	storage6
meta-cluster	✅
shard1-Master		✅
shard1-Slave					✅
shard2-Master			✅
shard2-Slave						✅
shard3-Master				✅
shard3-Slave							✅
compute1					✅
compute2						✅
compute3							✅

各组件的参数配置如下：

{
  "comp":[{
    "statement_timeout":1200000,
    "mysql_read_timeout":1200,
    "mysql_write_timeout":1200,
    "lock_timeout":1200000,
    "log_min_duration_statement":1200000
  }
  ],
  "metadata":[{
    "lock_wait_timeout":1200,
    "innodb_lock_wait_timeout":1200,
    "innodb_buffer_pool_size": "5*1024*1024*1024"
  }
  ],
  "storage":[{
    "innodb_buffer_pool_size": "10*1024*1024*1024",
    "lock_wait_timeout":1200,
    "innodb_lock_wait_timeout":1200,
    "fullsync_timeout":1200000,
    "enable_fullsync": "ON",
    "innodb_flush_log_at_trx_commit": 1,
    "sync_binlog": 1,
    "max_binlog_size": "1*1024*1024*1024"
  }
  ]
}

2.2 TiDB 部署拓扑及配置

组件/资源名	meta	storage1	storage2	storage3	storage4	storage5	storage6
pd	✅
tidb1		✅
tidb2			✅
tidb3				✅
tikv1					✅
tikv2						✅
tikv3							✅

相关组件参数：

server_configs:
  tidb:
    log.slow-threshold: 300
    log.level: "error"
  tikv:
    sync-log: true
    readpool.storage.use-unified-pool: false
    log-level: "error"
    rocksdb.defaultcf.block-cache-size: "10GB"
    rocksdb.writecf.block-cache-size: "6GB"
    storage.block-cache.capacity: "10GB"
    readpool.coprocessor.use-unified-pool: true
  pd:
    schedule.leader-schedule-limit: 4
    schedule.region-schedule-limit: 2048
    schedule.replica-schedule-limit: 64

2.3 OceanBase 部署拓扑及配置

组件/资源名	meta	storage1	storage2	storage3	storage4	storage5	storage6
observer1		✅
observer2			✅
observer3				✅
obproxy1					✅
obproxy2						✅
obproxy3							✅

相关配置如下：

writing_throttling_trigger_percentage: 100
memory_limit_percentage: 80
syslog_io_bandwidth_limit: 10MB
enable_async_syslog: True
builtin_db_data_verify_cycle: 0
enable_monotonic_weak_read: False
weak_read_version_refresh_interval: 0
enable_sql_audit: False
enable_perf_event: False
syslog_level: PERF
devname: eth0
mysql_port: 2881
rpc_port: 2882
zone: zone1
datafile_size: 150G
appname: obcluster
root_password: observer
proxyro_password: obproxy
enable_syslog_recycle: true
enable_syslog_wf: true
max_syslog_file_count: 4

3. 性能对比

此次性能压测数据量为 100 warehouse，Klustron与 TiDB 的对比测试，采用 TiDB 开源 go-tpc 工具。Klustron 与 OceanBase 的对比测试，采用 benchmarkSQL 工具。该工具也是 OceanBase 官方推荐工具。测试共分 3 轮，每轮的并发数逐步递增，每轮测试时长为 10 mins。

3.1 Klustron VS TiDB（v6.5.0）

	Klustron	TiDB
threads	tpmC	tpmC
50	74719.8	94909.6
100	124970.4	129772.6
200	170531.1	154680.8

3.2 Klustron VS OceanBase（v4.0.0）

	Klustron	OCEANBASE
threads	tpmC	tpmC
50	55827.43	50934.49
100	91339.6	35916.29
200	98710.18	34571.55

4. 总结

在与 TiDB 的对比测试中，可以看到随着并发的增加，Klustron 的优势逐渐体现。在与 OceanBase 的对比测试中，Klustron 的线性扩展能力优势较为明显。

从性能对比测试的结果来看，目前 Klustron 在同等的物理资源以及请求压力下，性能数据的表现相对于友商产品保持一定的优势。随着版本的后续迭代，Klustron 事务处理的能力也会进一步加强，从而为客户创造更大的价值。

在整个对比测试的过程中，我们对友商产品的参数调优是通过参考对应产品的公开文档进行的，因此可能也会有遗漏，导致没有展现出竞品的最优性能的情况出现。我们也希望和欢迎社区内有相关经验的同学能够仔细检查我们对 TiDB 和 OceanBase 的性能测试方法和参数设置，如果发现有问题的话指出来并与我们展开讨论。

END