PgBouncer简单测试

为什么80%的码农都做不了架构师？>>>   

测试环境，笔记本 4核8线程 16G内存，PostgreSQL v9.4.5取自EDB

默认参数测试（shared_buffer 128M）

1、初始化

./pgbench -i -s 1000 postgres

开始时没有计时，整个过程大约10分钟左右，执行完毕之后data目录有15.8G

2、测试PostgreSQL

我们启用64个会话8线程，每个会话完成6个事务后退出

[quanzl@bogon bin]$ ./pgbench -j 8 -c 64 -t 6 postgres -p 5432
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 64
number of threads: 8
number of transactions per client: 6
number of transactions actually processed: 384/384
latency average: 0.000 ms
tps = 174.962183 (including connections establishing)
tps = 176.286241 (excluding connections establishing)
[quanzl@bogon bin]$

这是我取到的最低结果，正常结果在180出头，偶尔到过190以上，从没有超过200。

2、测试PgBouncer

[quanzl@bogon bin]$ ./pgbench -j 8 -c 64 -t 6 popo1 -p 5431
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 64
number of threads: 8
number of transactions per client: 6
number of transactions actually processed: 384/384
latency average: 0.000 ms
tps = 214.251520 (including connections establishing)
tps = 214.912432 (excluding connections establishing)
[quanzl@bogon bin]$

同样是最低结果，最高到过232，大部分结果是220多，可以看出提升还是很明显的。

提升缓存测试（shared_buffer 1G）

1、PostgreSQL 测试方法同上

[quanzl@bogon bin]$ ./pgbench -j 8 -c 64 -t 6 postgres -p 5432
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 64
number of threads: 8
number of transactions per client: 6
number of transactions actually processed: 384/384
latency average: 0.000 ms
tps = 184.817262 (including connections establishing)
tps = 186.272290 (excluding connections establishing)
[quanzl@bogon bin]$

同样是最低值，其他依次为：

tps = 199.936374 (including connections establishing)
tps = 201.550601 (excluding connections establishing)

tps = 208.001447 (including connections establishing)
tps = 209.930247 (excluding connections establishing)

tps = 190.078591 (including connections establishing)
tps = 191.643495 (excluding connections establishing)

tps = 217.580382 (including connections establishing)
tps = 219.527798 (excluding connections establishing)

tps = 196.842624 (including connections establishing)
tps = 198.330960 (excluding connections establishing)

tps = 214.633296 (including connections establishing)
tps = 216.626217 (excluding connections establishing)

2、PgBouncer 测试方法同上

[quanzl@bogon bin]$ ./pgbench -j 8 -c 64 -t 6 popo1 -p 5431
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1000
query mode: simple
number of clients: 64
number of threads: 8
number of transactions per client: 6
number of transactions actually processed: 384/384
latency average: 0.000 ms
tps = 225.172794 (including connections establishing)
tps = 225.775740 (excluding connections establishing)
[quanzl@bogon bin]$

tps = 197.430422 (including connections establishing)
tps = 197.920393 (excluding connections establishing)

上边是最高与最低值，在大缓存、数据库体积与内存相当的情况下，整体来说已经没有什么提升。

重新初始化数据库，生成10倍数据量

因为是笔记本硬盘，初始化几乎三个小时

工作太多，没有记录结果，效果也是有的，提升幅度跟上边的测试差不多。

最大的差距

来自 -C 参数，每个事务分配一个新连接，这时候PG fork进程带来的额外系统开支影响非常明显，性能差距2倍以上。

转载于:https://my.oschina.net/quanzl/blog/540962