TcaplusDB Performance Baseline
The data access path of TcaplusDB is shown in the following figure:
1. Test Environment
Prepare a pair of machines at the storage layer. For the configuration of the machines, see the following table. The SSD disks are aligned at 4 KB and the data files and Binlog files are stored on different disks.
| Memory | Network card | CPU | Disk (data disk) | Disk (Binlog disk) |
|---|---|---|---|---|
| 128 GB | 10 Gigabit | 32 cores | Nvme disk | Nvme disk |
The ping delay in the cluster (from the access process to the storage process) is recommended to be less than 1 ms, and the ping delay from the client to the server is recommended to be less than 1 ms.
The test table is pre-split into 112 shards, and each shard is allocated 1 GB of memory's MMAP address space. A single piece of test data is 1 K, with an average of 2 G data pre-written to each shard. The total data volume is about 224 G, and the ratio of memory to disk data is about 1:1.
The test table engine parameters are set to: bnum=7500000#xmsiz=1000000000#lnum=1100000#xikmsiz=200000000#kfapow=6#kmapow=6#vfapow=10#vmapow=10.
2. Test Data
2.1. Storage layer (Tcapsvr) performance
Multiple access processes can be deployed according to the actual situation to ensure that the access process will not become a bottleneck.
Full write only
QPS is about 18 w/s, and the average request delay is about 5 ms.
Full read only
QPS is about 26 w/s, and the average request delay is about 4 ms.
Full read and write (read: write = 4: 1):
QPS is about 23 w/s, and the average request delay is about 4 ms.
Note: The above data are obtained when the size of a single test data is 1 K and the ratio of memory to disk data is about 1:1. It is only for reference. The actual performance data is related to the data model and access model of the app.
2.2. Access layer (Tcaproxy) performance
If only the performance of an access process is tested, deploy one access process.
The QPS of a single access process is about 5 w/s, and the average request delay is about 5 ms.
If the access process is a single-threaded model, only one CPU core is consumed. The app can horizontally expand multiple access processes according to specific models and load requirements.