MySQLi 持久连接填充并发用户答案

【问题标题】：MySQLi persistant connections filling concurrent usersMySQLi 持久连接填充并发用户
【发布时间】：2014-09-15 21:31:12
【问题描述】：

我在一家公司工作，该公司最近将网站的 PHP 代码从 vanilla MySQL 更新为 MySQLi，以领先于弃用更改。

在网络级别使用 64k 源 TCP 端口时，MySQL 出现了一些问题，并且出现故障。我们通过启用持久连接来解决这个问题。但是，我们现在遇到了一个新问题，即我们运行的查询并不总是重用现有连接，最终会填满所有连接槽 (200)。

我们运行的设置是这样的：

我们有多个数据库服务器（开发环境中为 4 个），每个客户端站点的复制表和单个数据库分布在服务器上（每个站点都有自己的架构）以提高性能。

我们有一个自定义查询解析功能，可以确定要连接到哪个主机、选择正确的架构并针对其运行查询。这不是问题，一切正常。

主数据库服务器受到连接的影响，填满然后拒绝任何新连接。

对于每个页面加载，每个主机只需要 1 次 mysqli_connect 调用。但由于某种原因，这些连接似乎从未被重用。甚至多次刷新同一页面都会为每次加载创建新的连接。

这正常吗？我本来希望重新加载相同的页面并获取相同的数据会重用在刷新之前创建的睡眠连接..

【问题讨论】：

【解决方案1】：

是的，这很正常。你应该阅读warnings on persistent connections。第一段通常足以吓跑你。在其他语言中，持久连接可以正常工作。

查看db服务器上的mysql进程时，是否看到很多空闲连接？您可能希望减少 mysql wait timeout 值以丢弃空闲连接。我通常在这个设置上相当激进（30 秒）并且系统扩展得很好（每天 100 万页浏览量）。

要真正领先于弃用更改，您应该考虑使用 PDO。无耻的插件：我写了my own db class，它管理连接、按需连接或根据需要重新连接。这允许非常低的超时设置，而不必担心连接断开。

【讨论】：

系统的其他部分（数据加载）使用 PDO，但我们没有时间来重建产品的整个数据层，它是一个非常庞大的产品，有很多查询。 MySQLi 是领先于弃用的捷径理想情况下，我们不希望使用持久性，但也不希望填满所有源 TCP 端口。不知道有没有中间地带。
我与另一个项目处于类似状态。减少 MySQL 的等待超时对我有用。持久连接实际上会使事情变得更糟。
他们确实让事情变得更糟了。然而，另一种方法是在每次页面加载时打开大约 5000 个 TCP 源端口。例如，如果我们对具有 150 个源数据库的对等方运行查询。它打开了超过 65k 的连接，然后没有其他任何东西可以做任何事情。
我不关注。您应该在每个页面加载时为每个数据库服务器（而不是数据库）建立 1 个连接。在一个每日页面浏览量为 400K 的站点上，我的主数据库服务器和从数据库服务器分别悬停在 100 个左右的连接上。您在 prod 中有多少个数据库服务器？
在生产中，我们有 1 个主服务器（也有站点数据库）和 4 个从服务器。问题是我们为涉及同行的客户处理数据/统计数据。任何特定的页面加载，取决于他们正在查看的位置，都可以通过 CURL 触发分布在所有服务器上的 150 个查询，然后对数据进行整理和显示。这很复杂。