java - HikariCP - 负载测试使性能下降到停止

Question

我一直在我的 spring boot 应用程序上使用 HikariCP，我开始使用 JMeter 进行一些负载测试。

我注意到我第一次运行测试时一切顺利，每个请求大约需要 30 毫秒。

但是每次我针对同一个应用程序实例再次运行我的测试时，响应时间都会变得更糟，直到它卡住并且我得到一大堆

Caused by: java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30019ms.
    at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:583)
    at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:186)
    at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:145)
    at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:112)
    at sun.reflect.GeneratedMethodAccessor501.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at net.bull.javamelody.JdbcWrapper$3.invoke(JdbcWrapper.java:805)
    at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286)
    at com.sun.proxy.$Proxy102.getConnection(Unknown Source)
    at org.springframework.jdbc.datasource.DataSourceTransactionManager.doBegin(DataSourceTransactionManager.java:246)
    ... 108 common frames omitted

我什至让应用程序闲置一天并再次尝试，但测试显示性能下降和相同的错误。

只有当我关闭应用程序时，它才能再次运行我的测试，但只有一次负载(1200 多个请求)。

当我开发测试时，我使用 H2 数据库运行我的本地应用程序，直到我将我的应用程序部署到运行 postgresql 的服务器上时才注意到任何性能下降。

因此，为了消除该变量，我让 JMeter 在我的本地 H2 应用程序上运行，结果显示性能下降。

这是我在本地应用程序(H2 数据库)上运行的测试场景，默认 HikariCP 轮询大小 (10)，使用 10 个线程。在应用程序停止响应之前，我设法运行了 25000 多个请求。

我绘制了请求:

此外，测试包括对 Spring Boot @RestController 的请求。

我的 Controller 调用了一个以@Transactional开头的服务(我调用了一些需要事务存在的遗留API，所以我马上打开它)。

假设我有 10 次并行请求此端点的测试。还假设我的代码可能有其他点用 @Transactional 注释。投票规模为 10 是否足够？

此外，尽管性能不佳，任何轮询大小都应该足够吗，或者出现这种轮询太忙和“锁定”的情况是否“正常”？

我也尝试将轮询大小增加到 50，但问题仍然存在。它接近之前测试的 25000 个请求(轮询大小为 10)，但如前所述失败了。

Answer 1

HikariCP 建议使用一个恒定大小的小型池，其中充满了等待连接的线程。 As per the docs the suggested pool size :

connections = ((core_count * 2) + effective_spindle_count)

A formula which has held up pretty well across a lot of benchmarks for years is that for optimal throughput the number of active connections should be somewhere near ((core_count * 2) + effective_spindle_count). Core count should not include HT threads, even if hyperthreading is enabled. Effective spindle count is zero if the active data set is fully cached, and approaches the actual number of spindles as the cache hit rate falls. ... There hasn't been any analysis so far regarding how well the formula works with SSDs.

具有小型数据集的内存中 H2 将比在不同服务器上运行的独立数据库更快。即使您在同一个数据中心运行，服务器之间的往返时间通常约为 0.5-1 毫秒。

首先尝试找到当前的瓶颈。如果应用程序服务器没有用完 CPU，那么问题出在其他地方，例如数据库服务器。如果您无法弄清楚当前的瓶颈在哪里，您最终可能会在错误的地方进行优化。