dbcp继续优化篇(statement cache)-优快云博客

通过启用statement缓存并适当设置缓存大小，成功将数据库请求时间降低了25%，从7ms减少到约5ms。该文详细介绍了如何在Spring容器中配置dbcp来实现这一优化。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

背景

昨天有同事反映，原先用jboss jndi数据源，现在换成基于spring容器的dbcp配置后，发现原先的请求从5ms，增加到7ms，性能下降了50%。

分析

在服务器上观察了一下请求的profile信息，发现一个请求90%多的时间都在mysql处理： 25%为prepared statement，70%为mysql read数据等待。

使用jvisualvm得到的一个time profile的结果:

发现很明显，preparestatement占了比较大的比例。

网上搜索了一把，找到一些相关内容，具体描述： (具体文档可查看附件)

大致意思也就是说：一个数据库查询，主要可分为两个阶段，一个是prepared statement，另一个是真正的数据库execute。

估算一下：

statement cost : 7ms * 25% = 1.75ms ，基本符合请求响应时间的现象。

解决

看一下，文档的基本描述：

dbcp的官方文档说明： http://commons.apache.org/dbcp/configuration.html

有两个参数：

poolPreparedStatements : 表明是否开启statement cache，默认为false，也就是不开启
maxOpenPreparedStatements : statement cache的大小，默认为-1，也就是不限制

因为以前使用的是jboss oracle-ds.xml配置，是有配置对应的cache。

<prepared-statement-cache-size>10</prepared-statement-cache-size>

最后的配置：

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
.... 
	<property name="poolPreparedStatements" value="true" />
	<property name="maxOpenPreparedStatements" value="10" />
....
</bean>

几点说明：

prepared statement cache是针对整个数据库连接池，是整个pool级别
statement cache使用了common pools中的GenericKeyedObjectPool，利用sql做为key。
单个connnection独享一个statement cache，也就是说maxOpenPreparedStatements是针对单个connection链接的，这里大家会有存在误用，须注意。
GenericKeyedObjectPool使用的是Map<Object , List> ，单个key可以对应一个list资源列表，也就是说一个sql key可以有一组list statement。

最后加上了statement cache的profile 结果：

已经没有preparestatment的，总体的响应时间也提升了25%在左右。

最后：

附上一下c3p0针对statement cache的配置描述：http://www.mchange.com/projects/c3p0/index.html#configuring_statement_pooling

简单的注意下，需要正确理解配置项的意义，不然会出现误用。

思考：

statement cache是否适合于所有的应用？
A: 针对业务复杂的应用，有大量的业务sql。使用cache是否会适得其反，cache命中率很低，反而增加了一个同步点
如何判断和设置statement cache的大小？
A: 通过btrace线上获取连接池的getMaxActive，这也是一种思路。