连接池中的最佳连接数答案

【问题标题】：Optimal number of connections in connection pool连接池中的最佳连接数
【发布时间】：2010-11-15 12:53:21
【问题描述】：

目前我们正在使用 4 cpu windows box 和 8gb RAM 和 MySQL 5.x 安装在同一个盒子上。我们正在为我们的应用程序使用 Weblogic 应用程序服务器。我们的应用程序的目标是 200 个并发用户（显然不是针对相同的模块/屏幕）。那么我们应该在连接池中配置的最佳连接数是多少（最小和最大数）（我们使用的是weblogic AS的连接池机制）？

【问题讨论】：

这个问题可能属于serverfault。
@Elijah - 非常与编程相关的问题。硬件配置描述用于详细说明问题。 SO 是回答这个问题的理想场所。
我建议 4 (CPU) 除以等待时间百分比。我建议 MAX 并行连接不超过 50 个，可能更少。您的 CPU 一次只能运行 4 个线程，再多的配置也无法与之匹敌。唯一有帮助的方法是处理 IO 等待，这取决于您的应用。
附加信息请求。在 pastebin.com 上发布并分享链接。 A) 完整（未编辑）my.cnf 或 my.ini 文本结果： B) SHOW GLOBAL STATUS；至少 24 小时正常运行时间后 C) 显示全局变量； D) 显示完整的处理程序； E) 用于服务器工作负载调优分析的完整 MySQLTuner 报告。 - github.com/pmachapman by peter@conglomo.co.nz 用于 WINDOWS MySQLTuner 0.8.4
您能否发布 2019 年 3 月 29 日要求的其他信息，以便分析您的实例的当前情况？

标签： java mysql performance weblogic connection-pooling

【解决方案1】：

您真的是指 200 个并发用户还是仅 200 个登录用户？在大多数情况下，浏览器用户每秒不能执行超过 1 个页面请求。因此，200 个用户相当于每秒 200 个事务。对于大多数应用程序来说，这是一个相当高的数字。

无论如何，我们以每秒 200 个事务为例。假设每个前端（浏览器）tx 需要 0.5 秒才能完成，在 0.5 秒中，数据库中花费了 0.25 秒。因此，您需要 0.5 * 200，即 WebLogic thead 池中的 100 个连接和 DB 连接池中的 0.25 * 200 = 50 个连接。

为了安全起见，我会将最大线程池大小设置为至少比您预期的负载峰值大 25%。最小值可以是最大值的一小部分，但代价是某些用户可能需要更长的时间，因为必须创建新连接。在这种情况下，50 - 100 个连接对于一个数据库来说并不算多，所以这可能是一个很好的起始数字。

请注意，要弄清楚您的平均事务响应时间以及平均数据库查询时间，您必须进行性能测试，因为您的加载时间可能不是您看到的时间一个用户。

【讨论】：

【解决方案2】：

这个问题有一个非常简单的答案：

连接池中的连接数应该等于WebLogic中配置的exec线程数。

原理很简单：如果连接数少于线程数，则可能有部分线程正在等待连接，从而使连接池成为瓶颈。因此，它至少应该等于 exec 线程的数量（线程池大小）。

【讨论】：

【解决方案3】：

调整连接池的大小并非易事。你基本上需要：

用于调查连接使用情况的指标
没有可用连接时的故障转移机制

FlexyPool 旨在帮助您确定正确的连接池大小。

【讨论】：

【解决方案4】：

您应该分析不同的预期工作流程以找出答案。理想情况下，您的连接池还将根据最近的使用情况动态调整实时连接的数量，因为负载通常是目标地理区域中当前时间的函数。

从少量开始，尝试达到合理数量的并发用户，然后再增加。我认为您可能会发现您的连接池机制在您的可扩展性方面几乎没有其他软件那么重要。

【讨论】：

+1，因为我想我正在发现“我认为您可能会发现您的连接池机制在您的可扩展性方面几乎没有其他软件那么重要”

【解决方案5】：

连接池应该可以根据实际需要进行增减。通过日志语句或通过 JMX 监视记录在运行系统上进行分析所需的数字。考虑为“检测到峰值：必须在 Y 秒内分配超过 X 个新条目”、“连接超出池超过 X 秒”等场景设置警报，这将使您能够在性能问题出现之前关注它们真正的问题。

【讨论】：

【解决方案6】：

这是需要在个人基础上进行测试和确定的事情 - 如果不熟悉它们，几乎不可能根据您的情况给出准确的答案。

【讨论】：

是否有任何公式/机制可以让我获得连接池中的粗略连接数？
您可能希望通过确定实际预期的并发事务数（或用户数）来开始计算

【解决方案7】：

很难为此获得确切的数据。它还取决于您未提及的许多因素 -

200 个并发用户，但他们的活动中有多少会生成数据库查询？每页加载 10 个查询？ 1 只在登录时查询？等等等等。
查询的大小和数据库很明显。有些查询在几毫秒内运行，有些则在几分钟内运行。

您可以使用“show processlist”监控mysql以查看当前活动的查询。这可以让您更好地了解在峰值负载下数据库中实际发生了多少活动。

【讨论】：

每页几乎有 1 个查询，每个查询最多 3000 条记录。

【解决方案8】：

根据我在高交易金融系统上的经验，如果你想处理例如 1K 每秒请求，并且你有32 CPU，你需要有1000/32 打开连接轮询到您的数据库。

这是我的公式：

RPS / CPU_COUNT

在大多数情况下，即使数量少得多，您的数据库引擎也能够处理您的请求，但如果数量少，您的连接将处于等待模式。

我认为提及您的数据库应该能够处理这些事务（基于您的磁盘速度、数据库配置和服务器能力）是非常重要的。

祝你好运。

【讨论】：

这是有道理的：D
什么是开放连接轮询？您的意思是对于 1000 个并发请求，池中最多需要大约 32 个可用连接数？
我很难相信这是准确的。通过这个公式，如果我有 1 个 CPU，我应该在池中配置 1000 个连接。这可能会将 CPU 固定在 100% 并且什么也做不了。同时，在假设的 128 个核心系统上，池中的连接数将少于 10 个。这可能会导致大多数核心在大多数查询不并行的事务系统中处于空闲状态。系统中的内核越多，此公式产生的并发度就越低，这是不对的。
还值得注意的是，只要您的查询在 1 毫秒或更短的时间内运行，您就可以在单个 CPU 系统上通过一个连接获得 1k RPS。在那种情况下你不需要 1000 个连接，所以这个数学真的不适合我