在 PHP 中从持久连接切换到非持久连接：我能期待什么？

Question

在过去的几周里，我们已经多次达到 1500 的 mysql 连接限制。突然之间 Threads_connected 爆炸了（300 -> 1500 在短短几分钟内）。

我们的前端服务器 (3x) 使用持久连接来连接到数据库服务器 (1x)。即使线程耗尽，我们的数据库服务器在资源方面（CPU、内存、IO）似乎也做得很好。

我正在考虑在我们的应用程序 (cakePHP) 中从持久连接切换到非持久连接。我能期待什么？

• 更高的 MySQL 负载？
• 前端服务器负载更高？
• 增加前端服务器的响应时间？

这样做是个好主意，还是我应该进一步增加连接限制？

Answer 1

由于数据库和应用程序服务器位于不同的机器上，您至少可以预期由于打开新连接而导致脚本执行延迟。如果两台服务器都在一个局域网中，那可能可以忽略不计。

显然，额外的任务会产生额外的负载，但我敢说这也几乎不会引起注意。与处理查询或脚本执行的任何其他操作相比，打开连接的开销很小。

现在，解决手头的真正问题。正如 mikey 所说，您可能需要调查问题的原因。如果使用持久连接，则每个 Web 服务器线程都可以打开并维护一个数据库连接。如果负载只有很小的峰值，这可能会大大增加连接数量。持久性和非持久性连接的问题实际上是相同的，只是非持久性连接会在之后消失，并且不会因不必要地占用内存而减慢未来的操作。

一般来说，如果您想保证每个数据库连接都成功，您必须确保您的 mySQL Server 可以处理与您的 Web 服务器接受并发连接一样多的连接。但是，在现实世界的设置中，您的 Web 服务器很可能会为与数据库无关的连接提供服务。 （图像、css、javascript 等）。考虑到这一点，您可以提供比数据库连接更多的 Web 服务线程，但有一个问题，这也可能是您的问题的根源：

如果有人以不同于正常使用模式预期的方式访问您网站上的大量页面，则上述规则不适用。例如，如果搜索引擎抓取您的网站。它们处理内容的顺序与浏览器不同。他们可以专注于您的 PHP 页面，打破每个客户端都会加载混合数据的假设。如果这是一个问题，取决于您与普通用户数量相比的页面数量。如果您的数据库服务器在高负载下变慢，从而延迟其他连接的处理，这种影响也可能是累积的。

因此，不使用持久连接并管理数据库服务器上的内存是有意义的，以便它可以以文件缓存和缓冲区为代价支持接近最大的连接，但返回到峰值结束后正常（更快）操作。

P.S.：确保您了解在使用所有连接时您的数据库将真正使用多少内存。 http://www.mysqlperformanceblog.com/2006/05/17/mysql-server-memory-usage/。不要只增加允许的连接数量而不确保您确实拥有所需的内存。尝试几次失败的连接尝试总比数据库服务器停止运行要好，因为它的缓冲区正在被换出。

Answer 2

您应该关闭 PHP 中的持久连接，它们不会像您期望的那样工作。实际上，与不使用它们相比，您最终会拥有更多的开放、空闲连接。手册中的警告实际上是警告连接不足。 http://php.net/manual/en/function.mysql-pconnect.php

您还应该阅读以下内容： http://www.php.net/manual/en/features.persistent-connections.php

底线是持久连接没有得到应有的重用。您看到的峰值可能是爬取您的网站的机器人，并且每次页面加载都建立了新的连接。

您可以期望您的连接不足问题会消失。如果您的 Web 服务器和数据库服务器之间的网络连接快速且可靠，那么始终建立新连接所增加的时间和负载将不会很明显。 MySQL 在这方面实际上非常有效。

Answer 3

我发现问题是由超载的 DNS 服务器引起的。

见Is DNS the Achilles heel in your MySQL installation?和How a DNS problem can put your Mysql server down