背景：
信创的大背景下，数据库是重要的一环，背靠国企，因此opengauss 也在我们的计划测试之列，测试opengauss，ssp就不可避免会使用到，本文记录了通过SSP压力测试的时候，总是和实际承载的tpmc相差很大。
数据库架构：一主两从
机器配置: 8C32G
版本：一主两从
ssp：单节点
版本：5.1.2
benchmark：5.0
1、通过ssp测试，并发10的情况下 tpmc达到100-200.
2、直接测试，并发为10的情况下，tpmc达到5000左右
问题：按说通过ssp有性能损耗，但是不至于说这么严重，无论怎么优化ssp的配置都无济于事，排查后发现还是配置有问题，修改配置后恢复正常。
同样条件下，可以达到4000多的tpmc，性能损耗在15%左右。
解决：去除了无关紧要的配置
mode:
type: Cluster
repository:
type: ZooKeeper
props:
namespace: governance_ds
server-lists: 10.26.223.160:2181
retryIntervalMilliseconds: 500
timeToLiveSeconds: 60
maxRetries: 3
operationTimeoutMilliseconds: 500
overwrite: true
rules:
- !AUTHORITY
users:
- root@%:root
- user2@%:kunpeng_1234
- sharding@:sharding
provider:
type: ALL_PERMITTED
props:
max-connections-size-per-query: 2
proxy-frontend-flush-threshold: 128 # The default value is 128.
proxy-backend-query-fetch-size: 1000
3、继续测试，随着并发的提升，性能急剧下跌，且有大量报错。而且性能损耗更严重。
