持久数据库连接-是还是不是?

你可以把它当作一个粗略的“规则集”:

对 ,使用持久连接,如果:

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

不 ,如果出现以下情况,请不要使用持久连接:

• 您的应用程序一小时只需要访问数据库100次。
• 有许多Web服务器访问一个数据库服务器
• 您在预处理模式下使用的是Apache。它为每个子进程使用一个连接,这可以相当快地进行扩展。(评论中通过@powerlord)

使用持久连接要快得多,尤其是在通过网络访问数据库时。如果数据库在同一台机器上运行,这并没有多大的区别,但是它仍然有点快。然而,顾名思义,连接是持久的,即它保持打开状态,即使它没有被使用。

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

Ergo:只在有很多请求的应用程序中使用它。

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

注意,mysql_close对于使用mysql_pconnect创建的连接是一个no操作(no op)。这意味着客户端无法随意关闭持久连接。当连接上的活动持续时间超过时,mysqldb服务器将关闭此类连接。 威特超时 . 如果 威特超时 如果是大值(比如30分钟),那么mysql-db-server就可以轻松到达 最大连接 极限。在这种情况下,mysql db将不接受任何未来的连接请求。 这时呼机开始发出哔哔声。

为了避免接触 最大连接 限制,使用持久连接需要仔细平衡以下变量…

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使用持久连接。您可能不想为了从持久连接中获得的小收益而邀请复杂的运行时问题。

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

在我看来,这个问题的真正答案是任何最适合你的应用程序。我建议您使用持久连接和非持久连接对应用程序进行基准测试。

Maggie Nelson @ Objectively Oriented 8月发布的 Robert Swarthout 用一些硬数字做了一个附带的帖子。两本书都读得很好。

在我看来:

当使用PHP进行Web开发时,大多数连接在执行页面的整个生命周期中都是“活的”。一个持久的连接会花费你很多开销,因为你必须把它放到会话中或者类似的事情中。

99%的情况下,在页面执行结束时终止的单个非持久连接将正常工作。

另外1%的时间,你可能不应该在应用程序中使用PHP,也没有完美的解决方案。

我本来想问同样的问题,但我不会再问同样的问题了,我只会添加一些我发现的信息。

• Are PHP persistent connections evil ?
• Persistent Database Connections

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

目前我仍在使用波斯连接,但计划在不久的将来切换到非持久连接。

一般来说,您有时需要使用非持久连接,并且最好有一个模式应用于DB连接设计(只要在您的上下文中使用持久连接没有什么好处)。