Java EE应用中的性能问题解决方案 — 第三部分 JDBC调整优化

声明：本文禁止未经本人同意的任何形式转载！如有转载需求，可与本人通过个人资料中的电子邮箱联系。对于未经同意的转载，本人将保留进一步行动的权利

JDBC连接池
大部分Java EE应用都需要通过JDBC连接后台数据库。因为创建数据库连接的消耗的资源巨大，所以应用服务器都选择缓存一定数量的连接对象并在各个请求处理之间共享。如果请求需要数据库的连接，但连接池中已经不能提供空间的连接，也不能创建一个新连接，那么请求就需要等待别的连接被释放后才能工作。反之，如果数据库连接池太大的话，就会浪费应用服务器的资源。本部分调优的全部努力就是旨在找出请求需要等待的最佳点，以便最小程度影响饱和的资源——如果数据库的压力很大的话，让请求在外面等待会更好。
 
连接不够的应用服务器可能的表现有：
应用性能低下
CPU利用率低
数据库连接池利用率高
线程等待数据库连接
执行线程的利用率高
队列中可能有请求等待
数据库服务器的CPU利用率不太高
 
当观察到这些现象时，可以调高数据库连接池的大小直至数据库连接的利用率在普通负荷的情况下大约在70%~80%之间。在整个过程中也需要注意数据库的负荷情况，我们也不希望对数据库产生过大的负荷压力。
 
JDBC prepared statement
对JDBC调优另一个重要的部分就是恰当配置JDBC连接中prepared statement的缓存大小。当应用对数据库执行SQL语句时，主要经历三个阶段：
准备
执行
检索
 
在准备阶段，数据库驱动向数据库发出请求，数据库需要生成查询的执行计划。在执行阶段，数据库执行查询，并返回结果集的引用。在检索阶段，应用遍历结果集并获取需要的信息。
 
数据库驱动能优化这一过程：第一次准备一个语句时，它就让数据库生成查询计划并缓存结果。在后续的操作中，已经准备好的语句(prepared statement)就能从缓存中加载进来，而不需要重回数据库获取。
 
当prepared statement的缓存尺寸太小时，数据库驱动将被强制再次准备无缓存的语句，如果重新回到数据库去数据的话将导致额外的处理开销和网络时间。Prepared statement缓存不足的主要征兆即是JDBC不断重复准备对同一语句的处理。
 
稍微要复杂一点的是，prepared statement是按照每用户的基础来进行缓存的，也就是说一个语句的缓存仅为一个连接准备，所以如果当应用有100个语句需要缓存而连接池中有50个连接时，就需要有足够大的空间来容纳5000条prepared statement。
 
在性能监控的环节中，确定应用一共运行了多少条不同的SQL语句，这样就可以根据每条语句执行的频率来决定prepared statement的缓存大小。
 
总结
每个应用的情况都是不同的，但是上述的一些问题还是比较多出现的。本文并未涉及具体的应用服务器产品及其调优方案，而是从整体的角度对一些通用的情况做出了分析。在真正实施调优的时候，需要根据业务需求、硬件条件、软件情况等多方面的内容做相应的调整。

Java EE应用中的性能问题解决方案参考资料下载
声明：本文禁止未经本人同意的任何形式转载！如有转载需求，可与本人通过个人资料中的电子邮箱联系。对于未经同意的转载，本人将保留进一步行动的权利！

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/BU_BetterYou/archive/2008/06/04/2510499.aspx