是否应该在我的数据库服务器或我的应用服务器上运行连接池?

前端之家收集整理的这篇文章主要介绍了是否应该在我的数据库服务器或我的应用服务器上运行连接池?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正准备开始使用PGBouncer,但我不确定它是应该在我的数据库服务器上还是在应用服务器上使用.如果它位于应用程序服务器上,则必然会有多个连接池,而不是一个用于共享的应用程序服务器的中央连接池,但是必须为每个新查询重新创建TCP连接,而不是也要进行池化.哪种是使用像PGBouncer这样的连接外观的“正确”方式,并且我对每个甚至有效的要点是什么?

注意:

对于那些偶然发现这个问题的人,请参阅PgBouncer FAQ(最后一个问题).

解决方法

就个人而言,我把它放在应用服务器上.这就是原因.

PGBouncer基本上实现了连接池,这是一个有用的(虽然有时令人讨厌的麻烦),通过消除设置与数据库的新连接的成本来减少整体应用程序延迟.在许多情况下,这是由数据库连接驱动程序本身完成的 – 请参阅Windows上的ADO.NET MSsql驱动程序,PHP上的PDO等.主要目的是最小化代码之间的时间成本“我需要说话到数据库“然后能够实际开始抛出sql命令.

上面提到的驱动程序实现了连接池,因此在数据库可以接收sql命令之前,代码必须做很少的事情.

PGBouncer是一个奇怪的例子,因为你仍然必须打开与PGBouncer守护进程的连接,无论它在哪里.因为您正在尝试最小化连接时间,所以将守护进程尽可能靠近应用程序代码是有意义的.理想情况下,您可以通过同一个盒子上的套接字连接,因为您不必通过TCP rigmarole来获取连接池.

和一切一样,YMMV.测试,测试,然后再测试一些.

猜你在找的MsSQL相关文章