2．性能问题分析原则

　　● 原则1：把事实与推测分开，总是用实际的证据来证明你的推测。

　　● 原则2：在没有足够证据之前，不对程序进行优化。

　　● 原则3：优先验证简单的假设。

　　● 原则4：日志文件中没有错误并不代表真的没有错误。

　　● 原则5：从系统到应用、从外到内进行层层剥离，缩小范围。确认是系统级问题还是应用级问题；确认是否为外部系统问题（如密码鉴权问题、EJB问题等）；确认是应用程序问题还是数据库问题。

　　● 原则6：范围缩小后，再分割成多个小单元，对每个小单元反复进行压力测试，来确定是哪个单元引起性能问题。

　　诊断性能问题，最常见的也是较难的判断的问题是：是应用程序还是数据库出了问题，还是两者都有？

　　这是因为应用程序、数据库、WebLogic Server（Tomcat）都不是孤立运转的。因此脱离应用架构单独运行测试（如SQL计时、JDBC计时、线程计时等）几乎没有作用。关键是对相互作用的了解。要熟知系统的性能度量方法，了解SQL的结构，了解用户发出的请求在跨越整个系统时的端对端/点对点计时、SQL的计时等；了解用户发出请求后所关联的线程、JDBC连接、数据库的活动及其之间的交互关系。

　　应用数据库典型的三大类性能问题分析如下。

　　1）过量的数据库调用

　　问题：常见的性能瓶颈来自过量的数据库调用，引发这些问题不一定是SQL查询的Execute()或Update()，而是应用程序与数据库的交互有关，例如，ResultSet操作，常见的问题是指定了过于精细的查询条件，然后使用ResultSet.Next()详细搜寻返回的数据。

　　解决办法：

　　从数据库中大量取得所要求的数据，避免应用程序反复回调数据库。

　　2）数据库连接池问题

　　问题1：连接池资源泄漏。

　　虽然可以通过WebLogic自带工具、Jprofiler工具或自编工具检测到数据库连接池资源泄漏，但是很难在应用程序代码本身准确定位泄漏的源头。

　　解决办法：仔细分析程序代码，是否没有close()连接？是否遗漏了finally块？或者尽管有close()但并没有成功？

　　问题2：连接池大小。

　　连接池过小会导致连接池满后，新的客户无法连接上系统，在日志中出现错误信息。一般的解决方法是增大连接池。但另一方面，连接池过大会造成资源无效损耗，可能会出现新的性能问题，那么连接池调到多大比较合适呢？

　　解决办法：

　　经验法则1，数据库连接池数＝线程池数每个线程需要连接数据库的平均数×1.1（1.1的含义是增加10%的峰值期负载），通常每个线程需要连接数据库的平均数是1，即当线程池数为120时，数据库连接池数就是132。

　　经验法则2，设置最初池大小＝最大池大小。