考虑到不同数据库产品的性质以及每个产品的独特性，配置连接池是非常困难的。对于Java应用程序，可以使用各种JDBC池实现。

在Tomcat（版本8）和SAP Cloud Platform Cloud Foundry环境中的TomEE容器中，我们可以选择使用容器管理的数据源。

这些环境附带两个数据库连接池实现。第一个实现（默认实现）是ApacheCommonsDBCP2.x项目的副本，重命名为另一个包。第二个实现是tomcatjdbc连接池。请注意，不同的实现可能有不同的属性。

但是，在线建站平台，如果您使用SAP HANA作为服务，贵阳大数据，为了在SAP云平台中轻松使用HDI服务，SAP Java buildpack提供了不同的池实现。帮助文档显示了如何为HDI管理的HANA设置数据源。请注意，在这种情况下，我们不必提供用户名或密码，工厂会在环境中查找服务并从这些凭据创建数据源—所有这些都是在运行时（12因子应用程序）和其他好处。

另一个常见实现，HikariCP由于其性能和可靠性而受到普遍青睐，什么是大数据，因此在连接池方面已成为现代事实上的标准，并默认出现在spring boot应用程序中。

这取决于使用哪个工厂实现的用例。对于这篇博文，我将使用SAP Cloud Foundry environment（canary），我的测试应用程序使用SAP HANA作为数据库，并通过HDI服务和SAP提供的池工厂使用它，并在SAP JVM buildpack的Tomcat容器中运行。我使用的游泳池工厂是

现在谈到游泳池大小，我在google上搜索了一下什么是游泳池大小，出现的各种博客是HikariCP/wiki/关于游泳池大小，管理Postgres中的连接，或者任何其他数据库和调整postgres连接池。

但是没有针对SAP HANA的，所以我决定自己做一个小实验。

强烈建议您阅读HikariCP wiki文章，因为它提供了一个非常好的主题视图。这个wiki以

"想象一下，你有一个网站，虽然可能不是Facebook scale，但仍然经常有10000个用户同时发出数据库请求——占每秒20000个事务。你的连接池应该有多大？你可能会惊讶，问题不在于有多大，而在于有多小！"

然后维基解释了为什么池大小应该很小（请阅读并观看视频）。大量的连接不一定会提高性能，事实上它会导致性能下降。在上述wiki讨论的情况下，将池大小从>1000减小到96，性能提高了50倍，建议进一步减小。

因此，池大小应该更小，好的，注意。

然后我开始了我的实验，也就是说，验证上面博客文章中所说的相同。

我写了一个spring控制器，当我们到达端点时，从容器提供的数据源获取连接，插入10个随机记录，选择这些记录并更新这些记录，最后删除这些记录。为了得到一些虚拟数据，我在数据库中插入了10000个虚拟值。代码在这里。它是一个多目标应用程序，部署在sapcloudfoundry（Canary）中。部署之后，我使用loadtest包检查服务器每秒可以处理的请求数。使用loadtest的好处是服务器必须根据我们使用该工具发送的请求吞吐量进行调整。

要配置池大小，我们可以在中的资源配置中使用maxActive属性上下文.xml文件。有关详细信息，请参阅前面提到的HDI文档。

maxActive是可同时从该池分配的最大活动连接数。

PS不要混淆maxActive和maxTotal，它们是不同池实现的不同属性，每个都有自己的属性。仔细阅读文档。

例如，

实验的基本思想是改变maxActive值，看看应用程序的吞吐量（以rps为单位）是如何变化的。鉴于我在金丝雀景观实际数字将不同，如果你复制实验。

我使用下面的测试命令

这击中网址端点连续30秒，模拟10个不同的用户和总共400个rps

这里是结果

结果是相反的，我们应该有一个小的池大小，如博客开始提到的，并在HikariCP和其他博客中默认推荐，其中交易率随着池大小的增加而降低。Hikari建议的默认值是10。还要注意的是，当池大小为500时，rps会降低一点。我认为这是因为应用层代码（测试代码生成随机数）和计算资源的限制。

让我们试着了解发生了什么。

如果你已经通过HikariCP wiki观看了视频，当我们有大量的连接时，数据库服务器从应用服务器接收大量的请求，这会导致高I/O阻塞。

如果没有，我将把它放在这里。

一个数据库服务器有3个主要资源，即CPU、磁盘和网络。每当数据库（网络I/O）发出查询请求时，基于这种情况（数据可能不会被缓存），数据必须从硬盘（磁盘I/O）加载到主存（RAM）并（由CPU）处理，结果将被发回（再次通过网络）。