Test conclusion
1: In terms of performance hikariCP>druid>tomcat-jdbc>dbcp>c3p0. The high performance of hikariCP benefits from the maximum avoidance of lock competition.
2: The druid function is the most comprehensive, sql interception and other functions, the statistical data is more comprehensive, and it has good scalability.
3: Comprehensive performance, scalability, etc., you can consider using druid or hikariCP connection pool.
4: The prepareStatement cache can be turned on, which will improve performance by about 20%.
Function comparison
| Features | dbcp | druid | c3p0 | tomcat-jdbc | HikariCP |
| Whether to support PSCache | Yes | Yes | Yes | no | no |
| monitor | jmx | jmx/log/http | jmx,log | jmx | jmx |
| Scalability | weak | Great | weak | weak | weak |
| SQL interception and analysis | no | stand by | no | no | no |
| Code | simple | medium | complex | simple | simple |
| Update time | 2015.8.6 | 2015.10.10 | 2015.12.09 | 2015.12.3 | |
| Features | Depends on common-pool | Ali open source, full-featured | Long history, complex code logic, and difficult to maintain | Great optimization, simple functions, originated from boneCP | |
| Connection pool management | LinkedBlockingDeque | Array | FairBlockingQueue | threadlocal+CopyOnWriteArrayList |
- Since boneCP was replaced by hikariCP and no longer updated, boneCP did not conduct research.
- There are reviews on proxool on the Internet that errors will occur in the case of high concurrency, so proxool did not conduct research.
- The function of druid is more comprehensive, and the scalability is good, it is more convenient to monitor and track the jdbc interface.
- c3p0 has a long history, and the code is extremely complex, which is not conducive to maintenance. And there is the potential risk of deadlock.
Performance Testing
Environment configuration:
| CPU | Intel(R) Xeon(R) CPU E5-2430 v2 @ 2.50GHz，24core |
| msyql version | 5.5.46 |
| tomcat-jdbc version | 8.0.28 |
| HikariCP version | 2.4.3 |
| c3p0 Version | 0.9.5-pre8 |
| dbcpVersion | 2.0.1 |
| druidVersion | 1.0.5 |
1: Get closed connection performance test
Test instruction:
- Both the initial connection and the minimum connection are 5, and the maximum connection is 20. No heartbeat detection in borrow and return
- The number of opening and closing times is: 100w times
- The test case and mysql are on the same machine, try to avoid the influence of io
- Response time of using mock and connecting mysql in different threads concurrently
Graphics:
mock performance data (unit: ms)
| 5 | 20 | 50 | 100 | |
| tomcat-jdbc | 442 | 447 | 1,013 | 1,264 |
| c3p0 | 4,480 | 5,527 | 7,449 | 10,725 |
| dbcp | 676 | 689 | 867 | 1,292 |
| hikari | 38 | 33 | 38 | 30 |
| druid | 291 | 293 | 562 | 985 |
mysql performance data (unit: ms)
| 5 | 20 | 50 | 100 | |
| tomcat-jdbc | 436 | 453 | 1,033 | 1,291 |
| c3p0 | 4,378 | 5,726 | 7,975 | 10,948 |
| dbcp | 671 | 679 | 897 | 1,380 |
| hikari | 96 | 82 | 87 | 78 |
| druid | 304 | 424 | 690 | 1,130 |
Test Results:
- Mock and mysql connection performance is similar, mainly because the connection is established during initialization and no connection is established later, which is consistent with the use of mock connection logic.
- Performance: hikariCP>druid>tomcat-jdbc>dbcp>c3p0.
- The performance of hikariCP is extremely excellent. hikariCP is known as the fastest database connection pool on the java platform.
- When hikariCP has high concurrency, there is basically no drop in performance.
- The performance of c3p0 connection pool is very poor, it is not recommended to use this database connection pool.
HikariCP performance analysis:
- hikariCP optimizes the (concurrentBag, fastStatementList) collection to improve concurrent read and write efficiency.
- hikariCP uses threadlocal cache connections and a large number of CAS mechanisms to avoid locks to the greatest extent. This alone may lead to an increase in cpu usage.
- 从字节码的维度优化代码。 (default inline threshold for a JVM running the server Hotspot compiler is 35 bytecodes ）让方法尽量在35个字节码一下，来提升jvm的处理效率。
2：查询一条语句性能测试
测试说明：
- 初始连接和最小连接均为8，最大连接为8。在borrow和return均不心跳检测
- 查询的次数为10w次，查询的语句为 1：打开连接 2：执行 ：select 1 3：关闭连接
- 测试用例和mysql在同一台机器上面，尽量避免io的影响
图形：
测试数据：
| 5 | 8 | 20 | 50 | 100 | |
| tomcat-jdbc | 2,178 | 1,495 | 1,769 | 1,818 | 1,858 |
| c3p0 | 3,237 | 3,451 | 4,488 | 5,994 | 7,906 |
| dbcp | 2,816 | 1,935 | 2,097 | 2,243 | 2,280 |
| hikari | 2,299 | 1,546 | 1,682 | 1,751 | 1,772 |
| druid | 2,297 | 1,551 | 1,800 | 1,977 | 2,032 |
测试结果：
- 在并发比较少的情况下，每个连接池的响应时间差不多。是由于并发少，基本上没有资源竞争。
- 在并发较高的情况下，随着并发的升高，hikariCP响应时间基本上没有变动。
- c3p0随着并发的提高，性能急剧下降。
3：pscache性能对比
测试说明：
- 通过druid进行设置pscache和不设置pscache的性能对比
- 初始连接和最小连接均为8，最大连接为8。在borrow和return均不心跳检测。并且执行的并发数为8.
- 查询10w次。查询流程为：1：建立连接，2：循环查询preparestatement语句 3：close连接
- 测试用例和mysql在同一台机器上面，尽量避免io的影响
测试数据：
| cache | 1,927 |
| not cache | 2,134 |
测试结果：
- 开启psCache缓存,性能大概有20%幅度的提升。可考虑开启pscache.
测试说明：
- psCache是connection私有的，所以不存在线程竞争的问题，开启pscache不会存在竞争的性能损耗。
- psCache的key为prepare执行的sql和catalog等，value对应的为prepareStatement对象。开启缓存主要是减少了解析sql的开销。