Pgpool II 4.1 性能显著增强，新特性列表

在我深入阐述内容之前，我将首先为博客标题提供一些解释。这个博客的标题是“Pgpool II 4.1以它的号角征服公牛”，Pgpool II的性能有着公牛一般的表现，“以它的号角征服”意味着4.1的发布在性能角度有着更强有力的表现。

经常出现的问题是直接使用PostgreSQL与在配置中使用Pgpool II等中间件时存在的性能差异。直观的讲，当我们为连接池或负载平衡或HA添加额外的活跃点时，在与直接访问PostgreSQL进行比较时，它会在某些情况下降低性能。性能差异应该非常小，否则会超出目的。我在说一些案例时要小心，因为你正在使用Pgpool的负载均衡功能和带有流复制的多节点配置，写入将转移到主节点，读取将分布在备用节点上以获得读取性能/可伸缩性。

Pgpool II 4.1主要是为性能发布，主要关注增加Pgpool II性能，同时缩小直接使用PG与结合使用中间件Pgpool ll之间的差距。该博客将深入介绍Pgpool II 4.1版本的一些性能特性，强调加速大型二进制插入的性能特性。

Pgpool II 4.1 GA将于年底10月/ 11月左右发布，我还没有确切的日期。

让我们快速浏览一下Pgpool II 4.1版本中的部分性能特性列表：

共享关系缓存是非常有趣的性能特性，它通过pgbench基准测试显示出巨大的性能结果。Tatsuo ishii撰写了一篇关于共享关系缓存的精彩博客，其中他还展示了有和没有共享关系缓存的基准测试结果。

http://pgsqlpgpool.blogspot.com/2019/03/shared-relation-cache.html

简而言之，共享关系缓存替换关系缓存（relcache）并提供在所有Pgpool II子节点之间共享的共享缓存。Pgpool II在执行简单查询时首次需要访问一堆系统目录表，使用共享关系缓存，信息将在所有子节点之间共享。因此，当添加新节点时，不需要再次查询系统表。共享关系缓存还有其他性能优势，请参阅上面的博客，了解有关功能和基准测试结果的更多详细信息。

在4.1之前的Pgpool II版本中，已经做了一些改进扩展查询协议性能的工作，Pgpool II团队已经完成了Pgpool II 4.1的数次提交，以提高扩展查询的性能，下面对此进行简要说明。

第一个提交是关于增强CopyData消息处理的性能。

“当执行COPY XX FROM STDIN（典型客户端是pg_dump）时，每个复制行数据都使用CopyData消息从Pgpool-II发送到前端。以前，一个CopyData消息之后是flush，这花费了很多时间。相反，现在刷新在后续通知消息或错误消息中完成。快速测试表明，这一变化使x2.5加速。

第二个提交是关于在向前端发送消息时增强性能。

SimpleForwardToFrontend（）负责向前端发送消息，只有当它是”D“（DataRow）或”d“（CopyData）时才会写入缓冲。其他消息类型立即写入套接字。但实际上这不是必要的。因此，如果消息不重要（“命令完成”，“准备查询”，+ *“错误响应”和“通知”），只需写入缓冲区。因此，能观察到10-17％的性能提升。“

第三个提交是关于在不需要时消除select（2）系统调用。

“我们的想法是在pool_read（）和pool_read2（）中的静态变量中检查select（2）超时参数集。如果它为-1，则表示在pool_check_fd（）中不会设置选择超时，这意味着我们可以避免调用pool_check_fd（）。此外，我从模块化的角度将pool_check_fd（）和其相关的函数移动到pool_stream.c。根据Jesper Pedersen的说法，这会略微提升性能。“

我在Pgpool II 4.1版本中最喜欢这个功能，Pgpool当前的负载均衡功能是基于连接或会话。这意味着当客户端会话连接到节点时（假设我们使用流复制具有辅助节点的主节点集群），该会话的读取查询将发送到该节点，当另一个客户端会话连接时，它将连接到另一个节点，并将查询发送到该节点以进行负载平衡。写查询始终是在主节点。

我上面描述的是会话级负载平衡，我们在Pgpool II 4.1中添加的是语句级负载平衡。此功能在下面的博客文章中有详细描述。简而言之，语句级负载平衡实质上是查询级的负载平衡，即每当pgpool将新查询在会话中响应处理时，发出新查询，将确定负载平衡节点。新的参数是“statement_level_load_balance””。如果将此设置为on，则启用该功能（可以通过重新加载pgpool.conf来更改参数）。

http://pgsqlpgpool.blogspot.com/2019/04/statement-level-load-balancing.html#more

这是执行大量二进制插入的另一个有趣的用户场景，我们看到直使用PG和通过Pgpool II使用PG之间存在很大差距。当用户在表中插入大量二进制数据时，我们进行了一个简单的测试，以查看两者之间的区别。在下面的测试中使用的sample.sql文件在二进制列中执行大插入，测试首先使用PG和Pgpool II执行而没有Pgpool II 4.1中的性能补丁，第二次执行是直接与PG没有Pgpool II，这是显示直接PG和Pgpool II之间的区别。第三次执行是使用Pgpool II和Pgpool II 4.1中的性能补丁。

结果不言而喻，没有4.1性能补丁，Pgpool II和直接PG之间的差异就像1100％一样大。应用性能补丁后，直接PG与Pgpool II仅略有不同。对于这个特殊而重要的场景，这对Pgpool II 4.1来说是一个显着的性能提升。

我不会详细介绍在Pgpool II 4.1中如何完成这项工作，有一些变化可以带来性能提升。重点是让Pgpool II使用另一个进程来管理日志，第二个更改就是在Pgpool中引入多个解析器。当Pgpool II需要知道所有信息时使用标准解析器，但是当我们在主/从配置中操作时，我们不需要任何额外的写查询信息，因为它们总是被发送到主节点。

- 使用Pgpool进行大量二进制插入测试而不使用性能补丁

postgres =＃\ i sample.sql
id
-
1
（1row）
INSERT 0 1 
Time：3098.821 ms（00：03.099）

- 使用直接PG进行大量二进制插入测试

postgres =＃\ i sample.sql 
id 
- 
1 （1row）
INSERT 0 1 
Time：246.685 ms

- 使用性能补丁的Pgpool进行大型二进制插入测试

postgres =＃\ i sample.sql 
id 
- 
7 
（1row）
INSERT 0 1 
Time：289.275 ms

虽然4.1主要是一个性能版本，但它还有其他一些有趣的东西，比如与postgres 12解析器和文档更新兼容。文档对于Pgpool II来说是一个薄弱环节，4.1对Pgpool II文档进行了一些增强，但IMO还不够。

在这篇博客中，我已经描述了Pgpool II 4.1发布的一些主要性能特性。因篇幅所限，4.1中其它性能特性在本博客中未提及。我们将在另一篇博客中介绍其余的性能功能。

如上所述，Pgpool II 4.1主要是一个性能版本，它旨在缩小直接PG和pgpool II之间的差距。请相信我们将在Pgpool II的未来版本中有更多的性能工作要做，Pgpool II最近几个主要版本的性能，稳定性，弹性和HA方面已经做了很多工作。

Pgpool II不是满足您所有数据库需求的解决方案，但它肯定会在负载平衡和HA方面取得很大进展。我们在2019年7月在北京的Postgres会议上讨论了Pgpool II的功能。

我们听到抱怨Pgpool II的稳定性以及看门狗（HA的Pgpool II组件）等问题，大多数情况下是因为在使用旧的Pgpool II版本带来的，这些版本在这些方面确实存在问题。

Pgpool II团队在最近的几个版本中添加了许多新功能和重构，现在Pgpool II非常稳定，有弹性、并且具有高性能。所以我敦促大家使用最新的稳定版Pgpool II，并不是说所有问题都得到了解决。

Ahsan Hadi是HighGo Software Inc.的开发副总裁。在加入HighGo Software之前，Ahsan曾在EnterpriseDB担任产品开发高级总监，Ahsan在EnterpriseDB工作了15年。EnterpriseDB的旗舰产品是Postgre Plus Advanced服务器，它基于开源PostgreSQL。Ahsan在Postgres方面拥有丰富的经验，并领导EnterpriseDB的开发团队，以构建向EDB的Postgres Plus Advanced Server添加Oracle兼容层的核心兼容性。Ahsan还花了数年时间与开发团队合作，为Postgres添加水平可伸缩性和分片。最初，他使用postgres-xc，这是一个多主分片集群，后来致力于管理向Postgres添加水平可伸缩性/分片的开发。

在EnterpriseDB之前，Ahsan曾在Fusion Technologies担任高级项目经理。Fusion Tech是一家总部位于美国的咨询公司，AHSAN领导了基于Java开发工作流的团队，负责在像沃尔玛这样的大商店里放置货架上商品应用系统管理。在加入Fusion Technologies之前，Ahsan曾在英国电信担任分析师/程序员，并开发了基于Web的网络故障监控数据库的应用程序。

Ahsan于2019年4月加入HighGo Software Inc（加拿大），领导多个Geo的开发团队，主要负责基于社区的Postgres开发以及开发HighGo Postgres server。