pgBouncer如何帮助加速Djang

Answer 1

PgBouncer通过充当维护连接池的代理来减少建立连接的延迟。如果您要打开许多到Postgres的短期连接，这可能有助于加快您的应用程序。如果你只有一小部分人脉，你就看不到什么胜利。

Answer 2

除了节省connect&disconnect的开销（在每个请求上都可以这样做）之外，连接池还可以将大量客户端连接汇集到少量实际数据库连接。在PostgreSQL中，活动数据库连接的最佳数量通常在（（2*core_count）+有效_spindle_count）附近。超过这个数字，吞吐量和延迟都会变差。

有时人们会说“我想支持2000个用户，响应速度快”，这是很有保证的，如果你试图用2000个实际的数据库连接来做到这一点，性能会很糟糕。如果您有一台带有四个四核处理器的机器，并且活动数据集已完全缓存，那么您将通过大约35个数据库连接将请求汇集起来，从而为这2000个用户看到更好的性能。

为了理解为什么这是真的，这个思想实验应该有帮助。假设一个只有一个资源共享的数据库服务器机器——一个内核。这个核心将在所有并发请求中平均地进行时间切片，而不需要开销。假设有100个请求同时出现，每个请求都需要一秒钟的CPU时间。核心对所有人都起作用，时间在他们中间分割，直到100秒后全部完成。现在考虑一下，如果将一个连接池放在前面，它将接受100个客户端连接，但一次只向数据库服务器发出一个请求，将连接繁忙时到达的任何请求放入队列中，会发生什么情况。现在，当100个请求同时到达时，一个客户机在1秒内得到响应；另一个客户机在2秒内得到响应，最后一个客户机在100秒内得到响应。没有人需要等待更长的时间才能得到响应，吞吐量是相同的，但是平均延迟是50.5秒而不是100秒。

一个真正的数据库服务器有更多的资源可以并行使用，但同样的原则是，一旦资源饱和，只会通过添加更多的并发数据库请求来破坏。它实际上比示例更糟糕，因为随着任务的增多，任务交换机增多，锁和缓存的争用增加，二级和三级缓存线争用，以及许多其他会降低吞吐量和延迟的问题。除此之外，虽然高work_mem设置可以在许多方面帮助查询，但该设置是每个连接的每个计划节点的限制，因此对于大量连接，您需要将此设置保留得非常小，以避免刷新缓存，甚至导致交换，这会导致计划变慢或散列表溢出到磁盘。

一些数据库产品有效地将连接池构建到服务器中，但是PostgreSQL社区采取的立场是，由于最好的连接池是在离客户端软件更近的地方完成的，因此他们将由用户来管理。大多数池将有某种方法将数据库连接限制为一个硬数字，同时允许比这个数字更多的并发客户端请求，并根据需要对它们进行排队。这是您想要的，应该在事务的基础上完成，而不是每个语句或连接。