使用sysbench测试阿里云RDS PostgreSQL性能

测试postgresql数据库性能的方法很多，例如pgbench, sysbench。

sysbench因为使用lua脚本编程，支持多线程，灵活度更高，测试复杂的业务逻辑建议用sysbench。

pgbench其实也很好，纯c写的，本身的开销小，测高并发低延迟的场景建议用pgbench。

首先要购买rds pg数据库实例

创建数据库用户

还需要购买同机房，与rds pg同vpc网络ecs或者同经典网络的ecs

在ecs端安装postgresql客户端

安装sysbench

初始化测试数据

测试oltp_pg.lua的内容，包含sql如下，其中第一条sql循环10次 ：

一个事务执行19条sql。

下面是本次测试的瓶颈分析

连接到阿里云rds管控平台，观察压测时间段的资源开销，哪个到了瓶颈就升级哪个资源。

如果是网络的问题，可以增加测试的并发来提升tps。

因为单个会话的链路延迟已经是没法降低的。

关于链路延迟量化分析的文章可参考

<a href="https://yq.aliyun.com/articles/35176">https://yq.aliyun.com/articles/35176</a>

rds pg的优化手段

因为rds链路较长，延迟会比本地延迟大很多。

但是如何量化这个延迟呢？

因为rds pg数据库服务器我们没法用qperf来测试，所以需要借助数据库本身来测试延迟。

重连数据库，测试数据库本身处理sql的rt

数据库处理rt平均约10微秒。

创建用于测试网络rt的函数。

清除数据

在ecs主机上创建测试脚本

压测

计算rt

扣除数据库自身处理开销10微秒，网络的rt约5.036毫秒。

延迟不小。

使用并发可以弥补这个链路延迟的短板问题，例如开启300个并发，再次测试。

吞吐量上来了，但是单个事务的rt还是摆在那里的。

另外一点，使用云数据库，建议多用udf，减少应用程序和数据库的交互次数，从而缩短整个业务逻辑的响应时间。