weblogic数据库操作的排查与优化
一个开发项目和商业创新是否成功要视其迅速检测、诊断和解决这些性能问题的能力而定。
由于它们的复杂性日益增加，与早期的僵硬应用程序环境相比，在这些多层的、分布式
J2EE
应用程序中的性能瓶颈更难以诊断。
J2EE
环境包含多层相互连接的软件和硬件组件，它们相互作用，满足任何既定的最终用户请求。性能团队的成员--设计师、开发者、应用服务器管理员和数据库专家--他们有自己对系统的见解，而且可能拥有他们自己的经验仓库或者"设备中心"的诊断工具。但是这个团队的成员怎样一同工作将问题分离出来呢？如果没有对
J2EE
系统所有组件的全面广泛的了解，如果他们不能相互交互，那么一位性能专家怎样找出哪台服务器速度慢？哪个组件速度慢？哪种资源不足？数据库引擎是主要瓶颈，还仅仅是一个次要因素呢？
[@more@]
应用程序、数据库、
WebLogic Server
都不是在孤立地运转。对这个问题的一种综合解决方法需要提高对这个相互联系的系统内所有几个部分的能见度：
WebLogic
资源利用和配置、应用程序架构以及数据库查询的执行，而且包括用户需求的了解和基本的硬件基础设施性能。
有了对这些子系统相互作用的了解，性能团队的成员就能有效地分离有问题的组件，并将问题交给正确的职能专家进行处理。
所以，对相互之间关系的了解是关键。
1，
过量的数据库调用
到目前为止，在
J2EE
数据库应用程序中最严重的性能瓶颈来自从用户应用程序对数据库引擎的过量调用。这些不必要的额外调用不一定是
SQL
查询的
Execute()
或
Update()
，但几乎总是跟与数据库的其他交互有关，例如
ResultSet
操作。一个常见的错误是指定了过于精确的查询条件，然后使用
ResultSet.Next()
详细地搜寻返回的数据，每次一行。这种作法会使应用程序的性能由
DBMS
内的数据集来决定--对于大的表格来说，搜寻量可能是巨大的；我曾见过客户站点的数据所执行的每个
SQL
查询都向
ResultSet.Next()
发出了超过
50,000
个调用指令。
如果有些数据处理必须在应用程序代码内进行，应考虑从
DBMS
大批取得所要求的数据，避免让应用程序反复回调数据库，从数据集里取回每一记录。
2，数据库连接池问题（JBDC）
当用户应用程序内的一个组件（通常是一个
EJB
）从一个连接池请求一个连接、查询或者更新某些数据，最后释放连接失败时，就会发生连接池泄漏。虽然通过检查
WebLogic JMX
性能度量（"连接数目"和"等待数目"）以及观察
DataSource.GetConnection()
缓慢的反应时间，能够很简单地检测到一个连接池迅速达到它的最大连接数目，但是很难在应用程序代码本身内准确指出泄漏的源头。具体情况要具体分析。
一个良好的经验法则是测量执行线程池的大小，乘以每个最终用户事务（线程）使用的并发数据库连接平均数，再加上
10%
的峰值时期负荷。平均每个事务的连接数通常是一个，无论所需的峰值负荷缓冲区是多大，
JDBC
连接池和执行队列大小都相同。通过使用大的
JDBC
池运行测试，并观察在任何给定的执行队列大小前提下所用
JDBC
连接池的平均值和峰值，可以反复调整该连接池的大小。还应该监控调用
Database.GetConnection()
的时间，以保证没有花太长的时间来等待
JDBC
资源。
在生产系统里使用
JDBC
池时，应牢记的第二点是：要设置最初池大小总是等于最大连接池大小。通过这样做，在池中创建所有连接的性能开销都将发生在
WebLogic Server
启动的过程中，而不是发生在最终用户运行时中。
3，错误组建的数据库查询
通过拆分具有排他性计时信息和调用次数的每个语句所执行的各个JDBC
操作，单个用户就能够排除是应用程序设计导致了问题。然后，该问题可以交给
DBA
，
DBA
使用其特有的
DBMS
性能工具进一步深入诊断表架构、索引和锁定。
在应用程序开发期间，当要执行的一个查询的结构已知，但是在运行时将使用不同的参数时，这时最好使用事先准备好的语句，并在运行时将参数传递给语句。这样可以缓存事先编译好的查询，该查询可以通过
WebLogic
准备好语句缓存来访问，而不用反复地将其传递给
DBMS
并在
DBMS
中进行反复地编译。
结束语
在一个承认频繁前期测试价值的组织内实行这样的经验法则，能够降低花费在无限
QA
循环上的时间，并且极大的加快应用程序的准备就绪过程。通过把资源如实地重新组合，使资源能够在硬件架构和期望的最终用户负荷方面密切反映生产环境的分段运输环境，就可以在引起生产问题和使顾客不满意之前检测到许多性能瓶颈，并加以诊断和解决。
评论