持久的数据库连接 – 是或否?

我在一个项目中使用PHP的PDO层进行数据访问,并且我一直在阅读它,并且看到它对持久性数据库连接具有良好的固有支持。 我想知道我是否应该使用它们。 我会看到在一个CRUD沉重的应用程序的性能优势? 是否有缺点需要考虑,或许与安全有关?

如果对你很重要,我使用MySQL 5.x.

你可以用它作为粗略的“规则集”:

是的 ,使用持久连接,如果:

  • 只有less数应用程序/用户访问数据库,即不会导致200个打开(但可能是空闲)连接,因为在同一个主机上有200个不同的用户共享。
  • 数据库正在通过networking访问的另一台服务器上运行
  • (一个)应用程序经常访问数据库

,不要使用持续连接,如果:

  • 您的应用程序只需要每小时访问数据库100次。
  • 您有许多Web服务器访问一个数据库服务器
  • 您在prefork模式下使用Apache。 它为每个subprocess使用一个连接,可以相当快速地进行升级。 (通过@Powerlord在评论中)

使用持久连接速度要快得多,尤其是在通过networking访问数据库时。 如果数据库运行在同一台计算机上,它并没有太大的区别,但速度还是比较快的。 但是 – 正如名称所述 – 连接是持久的,即保持打开状态,即使未使用。

问题是,在“默认configuration”中,MySQL只允许1000个并行“开放通道”。 之后,新的连接被拒绝(你可以调整这个设置)。 因此,如果您有20个Web服务器,每个客户端上有100个客户端,而且每个客户端每小时只有一个页面访问权限,那么简单的math计算将告诉您需要2000个并行连接到数据库。 这是行不通的。

Ergo:只用于有大量请求的应用程序。

简而言之,我的经验表明,应尽可能避免长久的连接。

请注意,对于使用mysql_pconnect创build的连接,mysql_close是一个无操作(无操作)。 这意味着持久连接不能被客户随意closures。 当连接上没有任何活动发生超过wait_timeout的持续时间时,这种连接将被mysqldb服务器closures。 如果wait_timeout值很大(比如说30分钟),那么mysql数据库服务器可以很容易地达到max_connections的限制。 在这种情况下,MySQL数据库将不会接受任何未来的连接请求。 这是当你的传呼机开始发出哔哔声。

为了避免达到max_connections限制,使用Persistent连接需要仔细平衡以下variables…

1. Number of apache processes on one host 2. Total number of hosts running apache 3. wait_timout variable in mysql db server 4. max_connections variable in mysql db server 5. Number of requests served by one apache process before it is re-spawned 

所以,在经过充分的考虑之后,pl使用持续的连接 您可能不想邀请复杂的运行时问题,以获得持久连接的小增益。

创build到数据库的连接是一个相当昂贵的操作。 持续的连接是一个好主意。 在ASP.Net和Java世界中,我们有“连接池”,这是大致相同的事情,也是一个好主意。

海事组织,这个问题的真正答案是最适合你的应用程序。 我会build议你使用永久连接和非永久连接来testing你的应用程序。

8月份的Maggie Nelson @ Objectively Oriented发表了这篇文章, Robert Swarthout做了一些相关的post。 这两个都是不错的读取。

我会问同样的问题,而不是再次提出同样的问题,我只是添加一些我发现的信息。

  • PHP的持续连接是邪恶的?
  • 持久数据库连接

还值得注意的是,较新的mysqli扩展甚至不包括使用持久数据库连接的选项。

我目前仍在使用persive连接,但计划在不久的将来转变为非持久连接。

在我的愚见:

当使用PHP进行Web开发时,大部分的连接只会在页面执行期间“活”。 持续的连接会花费你很多的开销,因为你必须把它放在会话或一些这样的事情。

99%的时间在页面执行结束时死亡的单个非持续性连接将工作得很好。

另外1%的时间,你可能不应该使用PHP的应用程序,并没有完美的解决scheme。

一般来说,有时候需要使用非持久性连接,并且将单个模式应用于数据库连接devise(只要在上下文中使用持久连接的好处相对较less)是很不错的。