Jet*_*nez 5 connection-pooling hikaricp
我已经为一些应用程序实现了 HikariCP。到目前为止，在“最简单”的情况下，它运行得非常好，甚至提高了性能并显示了我们应该尝试优化的地方。
无论如何，该应用程序位于 RAID 上具有 4 个 HDD 的服务器中，并且它是一台 8 核机器。我们还有另一个应用程序将托管在云中，并带有 SSD 存储。
我知道PostgreSQL 团队给出的公式解决了最大大小池的问题，但根据 Hikari 的文档，SSD 的行为尚未分析。这个“尚未”让我去寻找答案，但由于我的谷歌搜索效果不佳（我可能使用了错误的关键字），所以我来到这里。
有谁知道这个公式如何与 SSD 进行缩放？一个简单的猜测是，如果我实际上无法effective_spindle_count考虑 SSD 和 HDD 的不同，那么我可以根据读/写速度或其他因素来调整数量，但我怀疑是否那么简单。
再会！
在我提出问题时引用的同一个链接（这是文章中的引用）中，添加了有关带有池的 SSD 的新信息。
tl;dr 是“由于寻道时间更少/没有，池中的连接越少越好”，他们给出了一个例子，每个 CPU 核心只有一个连接是理想的，因为它不会改变上下文，因此开销更少。他们没有提供明确的答案，因为“只有当阻塞创造执行机会时，更多线程才会表现得更好。 ”，我认为这是公平的。
在这一点上，我倾向于相信池大小等于系统中的核心数量是理想的，因为开销很低甚至没有开销，同时在发生任何阻塞时可能有比所需更多的线程操作开始。
我缺乏专业知识来给出明确且有充分依据的答案（只要我们能得到答案，我绝对可以接受被证明是错误的），但从我所阅读和理解的内容来看，我认为是安全的说：
如果应用程序的数据源从 HDD 读取：请遵循公式。
（最大）连接数 = ((core_count * 2) + effective_spindle_count)
如果应用程序的数据源从 SSD 读取：池大小应等于运行应用程序的计算机的核心数。
（最大）连接数 = core_count
当然，再次引用这篇文章：池大小最终是针对部署而言的。