《PolarDB-X开源分布式数据库实战进阶》——对PolarDB-X进行TP负载测试（3） https://developer.aliyun.com/article/1228676?groupCode=polardbforpg
压测中的常用性能指标包含QPS、TPS、RT。
QPS指每秒查询数，从数据库层面来看指1秒内执行的SQL语句数，包括增删改查。
TPS指每秒事务数，从数据库层面看，既包含了commit事务，也包含rollback事务。TPS在不同语境下具有不同的含义：在数据库系统中，指每秒执行的事务数量；在web应用中，可以理解为对页面的一次访问；在区块链中，代表产生交易的速率。
RT指响应时间，反映了执行一个请求时，从开始到收到响应数据所花费的总体时间。这也是用户感受最为直观的一个指标，在实际应用中又分为客户端RT与服务端RT，网络环境越差，两个RT的差距也会越大。
三个性能指标相互之间存在关联。假设运行的Sysbench是单线程的点查，如果每条查询的平均RT是1ms，则意味着在1秒内可以同步执行1000次点查，也即：在并发数为1的情况下，QPS是1000。
选择一个历史任务进行查看，平均时延为0.47ms，1000/0.47=2127，与上图中的2112.86基本相等，也验证了上述理论。
系统的监控指标包括饱和度、延迟、流量以及错误。
饱和度主要用于衡量资源的使用量，比如CPU使用率、内存使用率、IOPS使用率、任务队列的长度等。
延迟反映了完成操作所需要的时间，比如网络延迟、IO wait、接口调用延迟、数据同步延迟等。
流量则用于衡量系统的繁忙程度，比如磁盘流量、网卡流量、核心接口的请求速率，web服务通常更关心请求速率。
错误包含了显式错误与隐式错误，比如可能直接报错，返回了错误，也可能没有报错，但是返回了非预期的结果。错误反映了系统当前的运行状况，一般体现为宕机、进程crash、主备切换、核心功能错误等。
不同角色也会关注不同的指标项，比如DBA可能更关注数据库的饱和度，可以根据业务周期对系统的性能、水位进行评估，从而判断是否要进行扩缩、容升降配等操作；应用开发人员则会更关注QPS和RT两个指标。
使用CPU或IO等机器指标，确实可以一定程度反映数据库的负载。但如果瓶颈在于数据库系统自身，比如有强烈的锁冲突，此时底层的硬件资源利用率难以衡量数据库本身的饱和度。因此需要数据库层面提供更多维度的监控指标来定位性能瓶颈。
PolarDB-X提供了丰富的性能指标，其为计算存储分离架构，因此监控指标也分为计算节点和存储节点两大类。
计算节点里的指标有CPU内存使用率、逻辑QPS、物理QPS、逻辑RT、物理RT等。存储节点则有CPU内存使用率、存储空间QPS、buffer pool命中率、读写次数行锁、IOPS等。
结合以上监控信息，有经验的DBA或数据库开发人员可以更轻松地定位数据库的性能瓶颈，从而对当前的数据库进行优化。
《PolarDB-X开源分布式数据库实战进阶》——对PolarDB-X进行TP负载测试（5） https://developer.aliyun.com/article/1228673?groupCode=polardbforpg
