J2EE性能问题的诊断示例

诊断示例

       以示例分析如下。您的应用程序呈现出的故障征兆是：系统运行随负载的增加越发缓慢。用户叠加的数量越多，系统运行速度就越慢。负载退出后，系统便自行恢复 正常运行状态，而无任何副作用。通过评估这一早期故障征兆，查找结果如下（时间测量值是指单个典型事务处理的端到端完成时间）

       表一、应用程序性能随负载的增加逐渐下降

      

负载（用户数）	来回时间（毫秒）
10	300
50	471
100	892
150	1067

       您可由此稍作推测：也许这一故障现象可归咎于某个包含编码缺陷的组件，或者某个后台系统的系统瓶颈，又或者是由一个同步阻塞点所导致。您能够分辨它们的不同吗？假定你也同时测量了负载状况下应用服务器的CPU总体使用率，结果如下

       表二、问题看来是一个“等待”瓶颈

      

负载（用户数）	来回时间（毫秒）	CPU总体使用率(%）
10	300	30
50	471	33
100	892	37
150	1067	41

       看来系统并不是CPU密集型的，这就是说系统白白浪费掉大量等待时间。但这是来在内部（如同步通信阻塞）还是外部（如数据库运行缓慢）呢？假定我们又多收集了几个数据，具体如下

       表三、SQL语句运行缓慢是问题所在吗

      

负载（用户数）	等待数据库连接的线程数	JDBC查询时间（毫秒）
10	2	58
50	3	115
100	3	489
150	4	612

       看来，等待数据库连接的内部瓶颈并不是问题所在。是JDBC查询本身出现了问题。不单是JDBC查询时间随事务处理的总体时间而变化，其性能的降低还能够 解释整体性能下降的大部分原因。至此为止，我们的工作尚未完成。您还有三个主要推断有待筛选：数据库本身是否运行缓慢；应用程序是否有不合理的数据库访问 要求；应用程序与数据库间的某个桥接层是否出现问题。借助于数据库厂商提供的专用工具，从该角度查看响应时间。您希望获取的数据如下

       表四、实际原因是数据库中的SQL语句执行慢

      

负载（用户数）	JDBC查询时间（毫秒）	数据库SQL的实际运行时间（毫秒）
10	58	43
50	115	97
100	489	418
150	612	589

       如果并未查看到上述数据，您则需要重新着手分析 JDBC驱动程序，希望能够从中发现某类同步问题（需要注意的是CPU并无崩溃）。所幸的是，在本例中您已经把具体问题界定到某个数据库查询。确定查询要 求是否合理，需要具备该领域的专业知识，需要对系统很熟悉。在本例中您却只需通过将一个无索引域查询与一个外来码查询相比较，就成功诊断了问题。您还能够 与数据库管理员并肩作战，通过他来修改索引模式，以提高查询速度。至此您已经圆满地实现了预期目标。

结束语

       诊断J2EE应用程序的性能瓶颈会是一个艰难的过程。运用你的智慧，深入推测以探寻事实真相，以确凿的证据来确认您的假设。本文通过对分类标准的有益尝 试，引导您进一步深入思考和实践探索。就如同进入调试阶段，如同经过玄思冥想方能修炼成功的魔法，慎思明辨才是带您走出困境的唯一途径。