系统调优的建议

1．性能瓶颈定位3

1.1定位执行时间较长的SQL语句3

1.2定位执行次数较多的SQL语句4

1.3不恰当的数据库锁定机制与同步机制4

2．优化实做注意事项5

2.1结合系统性能要求对系统可能的瓶颈点进行甄别和评估5

2.2建立测试基线，优化和测试相结合5

2.3优化的时间分配5

2.4改良与革命6

3．总结6

****系统上周进行系统性能测试。测试的第二天下午，我在现场，目睹了系统测试中发现的一些性能问题，当时也给参与测试的开发人员提出了一些建议。经过几天对优化问题的思考和整理，并结合自己以往的系统开发、调优经验，提出个人的一些意见和建议，仅供参考。

1．性能瓶颈定位

对系统瓶颈的准确定位是调优的第一步，也是最为关键的一步。系统响应时间较长和数据库负载重有相当的关系。应用系统同数据库系统的交互主要通过SQL语句完成，数据库的负载过重主要由以下几个方面原因造成：执行时间较长的SQL语句，执行太过频繁的SQL语句，不恰当的数据库锁定机制。

1.1定位执行时间较长的SQL语句

执行时间较长的SQL语句是系统响应时间和性能的主要杀手。找到并且优化这些极为耗时的SQL语句是系统调优极为关键的一部。

在一个事务中如果包含一个执行时间很长的SQL，并发不用上到很大，就会有大量的前台请求会因为TimeOut而rollback。

如何定位这些堪称性能杀手SQL，大致说来有三种途径。

一是开发人员自己根据经验分析源码，进行判断和挑选；

二是在性能测试时，观测web server中所有Servlet的响应时间，找出那些平均执行时间最长的那些Servlet。开发人员根据这些Servlet进行分析，找出在这些Servlet在执行阶段最为耗时的SQL；

三是在进行性能测试时，在Oracle数据库一端由DBA统计出占用时间最长的N条语句。N的具体取值可以根据实际情况来定。一般一次获取前25条最占用时间的SQL语句就可以。

通过上述3种途径，应该可以定位出耗费系统资源最多的那些SQL语句。然后对这些SQL进行优化，改进系统效率。

在优化SQL的同时，检查数据库索引的建立情况，尽量避免在查询中对数据库表作全表扫描操作。Oracle9i 在分析SQL语句建立执行计划时缺省使用的是基于执行成本的CBO方式。及时的对数据表及索引进行analyze，以更新建立查询执行计划所需的信息也很必要。

1.2定位执行次数较多的SQL语句

执行次数较多的这些SQL，不像那些执行时间较长的SQL那样对系统的性能影响的那样直接，但是一样“危害”较大。这些SQL使得数据库始终陷入繁忙状态，致使其性能下降，效率降低。

对执行次数较多的这些SQL的侦测同定位执行时间较长的SQL语句类似也是可以从系统源码分析，WebLogic运行监控，数据库监控这几方面进行。通过上述操作，找出那些虽然执行时间可能不长，但是

执行最为频繁的SQL语句。

对于这些执行次数较多的SQL语句，可以根据其对系统的作用区分对待进行优化。

1.3不恰当的数据库锁定机制与同步机制

不同数据库系统的锁定机制是不同的。对于Oracle系统来说，其锁定机制在所有的RDBMS中算是最为灵活的。在Oracle默认的事务级别中，写操作只会阻塞写操作，而不会阻塞读操作。锁定操作是为了保证业务数据的一致性和完整性。但是锁定操作降低了系统的并发性，对系统的性能有一定的影响。

检查系统中数据库事务操作的涉及数据库锁定的操作，尽可能的减少从锁定到提交的时间间隔，减少事务执行时间，提高系统并发性能。

还有JAVA中的Synchronize代码段同一时间只允许一个线程执行，所以对于并发的影响也较大。

2．优化实做注意事项

系统瓶颈点定位以后，对于系统的优化就是下一步的工作，下面就优化工作提几点自己的意见和建议。

2.1结合系统性能要求对系统可能的瓶颈点进行甄别和评估

通过测试发现的性能瓶颈可能只是整个系统性能问题的一部分，可能还有很多潜在的问题未暴露出来。所以首先对系统的性能问题进行通盘考量是很有必要的。通过考量，甄别和确定系统中可能的瓶颈点，并对其进行评估，分清主次，确定优化步骤和方案。

2.2建立测试基线，优化和测试相结合

通过建立测试基线，有助于了解对系统进行优化后，在系统性能方面带来的改进。

优化和测试一定要结合起来，根据测试目标要求，用已确定的测试用例，对优化后的系统进行测试。通过这样的小步迭代，用测试检查和巩固优化效果。

2.3优化的时间分配

对系统的优化其实是没有止境的。所以如何在有限的时间里面，充分利用有限的资源，达到优化目标是一件充满挑战的事情。

80/20原则也很适合系统优化。即用80%的精力集中解决最影响性能的那20%的瓶颈点。抓大放小，有的放矢，在有限的时间里，充分提高优化的效率和效果。

还有一个原则是优化时，优先选取优化前后绝对时间差最大的环节进行优化。举个例子，执行时间从30秒提高到3秒与3秒提升到0.3秒同样是执行时间提高了10倍，但是对系统性能的贡献却是大相径庭。

2.4改良与革命

对于系统优化大致有两条道路可供选择，即渐进改良与彻底革命。建议根据性能目标，认真评估，合理的进行选择。

改良的短期风险较小，也不会花费很长的时间。但是改良有其局限，即不可能完全摆脱原有架构的限制，其对系统性能的贡献有其最终极限。

革命的风险较大，往往会涉及对系统架构方面的调整。这对时间的要求就较高，而且失败的可能性也不容忽视。对系统架构方面的调整对于整个系统而言是伤筋动骨，成功了自然皆大欢喜，但是弄不好有可能比先前还要差，得不偿失。

所以对优化目标必须结合系统目前的实现进行认真地评估和考量。选择优化策略与方案。建议尽可能在不涉及系统架构变迁，由外及内，采用渐进改良的方案逐步进行系统优化。

3．总结

对J2EE应用的优化是一个系统工程，由于其架构复杂层次繁多，不容易一蹴而就。如何在有限的时间里合理的规避风险已完成优化任务，达到系统性能目标要求，是一件充满挑战的事情。希望这些建议能对顺利完成系统的优化工作有所助益。