PostgreSQL Replication之第八章与pgbouncer一起工作（4）

8.4 提升性能

从一开始考虑pgbouncer的时候，性能就是一个关键的因素。为了确保高性能，有些问题必须认真对待。首先，确保参与您设置的所有节点相互之间的距离较近。这对于降低网络往返时间有很多的帮助，从而提升性能。减少调用fork()的开销和为了性能的提升而付出网络时间是没有必要的。正如在大多数情况下，降低网络时间和延迟绝对是一笔巨大的开销。

基本上，pgbouncer可以放到一台专用的pgbouncer服务器上，直接放在一个数据库节点，或者放在web服务器上。一般来说，建议不要把数据库基础设施放到web服务器上。如果您有更大的设置，专用服务器可能是一个不错的选择。

经常被遗忘的另外一个问题是和池本身相关的的问题。正如我们已经描述的，pgbouncer的思想是加速获得一个数据库连接的过程。然而，要是池没有足够的连接又怎么样呢？如果没有多余的数据库连接，将会发生什么？那么，您将会花费大量的时间通过在后端派生它们来创建这些连接。要解决这个问题，建议为min_pool_size设置一个合理的值。如果许多连接在同一时间被创建(例如，如果一个web服务器重新启动)，这一点尤为重要。务必确保您的池大小合理，以维持高性能(就创建新连接而言)。

[ min_pool_size的完美的值将取决于您正在运行的应用的类型。但是，我们的经验是使用比默认值较高的值。]

8.4.1 简单的 benchmark

在本章中，我们已经介绍，如果应用必须创建许多短连接，使用pgbouncer非常有利。为了证明我们的观点，我们编写了一个极端的例子。我们的目标是运行一个测试，做的越少越好—我们只是要测量打开一个连接我们需要多少实际。要做到这一点，我们安装了一个只有一个CPU的虚拟机。测试本身会使用pgbench(一个广泛用于检测PostgreSQL的contrib模块)。

我们可以很容易地创建我们自己的一个测试数据库：

pgbench -i p1

然后，我们可以写一个我们自己的简单的SQL命令，它应该被重复地执行：

SELECT 1;

现在，我们可以对我们的标准PostgreSQL安装运行一个极端的测试：

hs@VM:test$ pgbench -t 1000 -c 20 -S p1 -C -f select.sql

starting vacuum...end.

transaction type: Custom query

scaling factor: 1

query mode: simple

number of clients: 20

number of threads: 1

number of transactions per client: 1000

number of transactions actually processed: 20000/20000

tps = 67.540663 (including connections establishing)

tps = 15423.090062 (excluding connections establishing)

我们要运行20个并发连接。它们都执行1000个单个事务。–C表明，每个单个事务之后，检测将会关闭打开的连接并创建一个新的连接。这是一个没有池(每一页可能是一个单独的连接)的web服务器的一个典型的情况。

现在，请记住，这个测试的设计看起来很丑陋。我们可以看到，保持连接活着将确保在我们的单个CPU的虚拟机上我们可以每秒执行大约15,000个事务。如果每次我们必须分出一个连接，我们将下降到每秒67个事务—正如我们之前所说的：这类开销是值得深思的。

现在，让我们通过pgbouncer连接到PostgreSQL来重复那个测试：

hs@VM:test$ pgbench -t 1000 -c 20 -S p1 -C -f select.sql -p 6432

starting vacuum...end.

transaction type: Custom query

scaling factor: 1

query mode: simple

number of clients: 20

number of threads: 1

number of transactions per client: 1000

number of transactions actually processed: 20000/20000

tps = 1013.264853 (including connections establishing)

tps = 2765.711593 (excluding connections establishing)

正如您可以看到的，我们的吞吐量已经上升到了每秒1013个事务。这是之前的15倍—确实是一个不错的收益。

然而，我们也必须看到，我们的性能水平已经下降了，如果我们没有管理到pgbouncer的连接。请记住，bouncer，检测工具和PostgreSQL都运行在相同的单个CPU上。这在这里确实有影响(在虚拟化环境中，上下文开关不太便宜)。

请记住，这是一个极端的例子—如果您用较长的事务重复这个相同的测试，您将会看到差距将会逻辑地变得更小。我们设计的例子已经表明了我们的观点。