摘要:我提倡使用最小化资源的方式做一次压力测试，排除大部分浅显的应用问题。最小资源的意思，即在pc环境，使用应用可以运行的最小资源状态下，进行压力测试和性能问题侦测的工作。
前面看到有人讲j2ee的性能调优，虽然这块不是自己的专长，但是猪养多了，也忍不住跳出来说几句。
虽然几乎每本讲性能调优的书籍开篇都会提，没必要的情况下就不要做调优，但是我个人还是认为，所有系统在上线前，都应该做一次基本的压力测试并对相关的性能问题进行检测， 但是迫于资源压力，很多项目都无法做正规的压力测试，一直到系统上线出现问题，才倒回来找原因。 而正规的压力测试，往往因为需要严格模拟生产环境，需要耗费大量的资源，各类专家配合解决问题，并不是那么轻松的可以做下来的。
而j2ee应用的特点就是以复杂性来回避传统问题，所以任意一个j2ee的部署，相对于php那样的结构都是比较复杂的。系统一旦发生性能问题，必须在程序、数据库、应用服务器、jvm、操作系统几大块中交叉进行考虑，根据实际情况问题，问题的原因可能异常复杂。我们可以想象一个项目，从来不做UT不做IT ，只做一次UAT，然后直接提交给用户上线以后，修补错误的困难度和成本。
经常看到一些调优的最后解决方案，可以肯定，几乎80%以上都是一些低级的程序错误导致的，剩下的20%虽然可能是用硬件，os参数调整等等问题解决了，但是其中很大一块，归根到底也是程序的问题。 而在我们回顾这些错误的时候可以很惊人的发现，大部分都是一些低级错误。
我提倡使用最小化资源的方式做一次压力测试，排除大部分浅显的应用问题。最小资源的意思，即在pc环境，使用应用可以运行的最小资源状态下，进行压力测试和性能问题侦测的工作。这种做法的优点如下。
1. 环境容易搭建， 特别是不需要考虑大型硬件和网络条件等等，也回避了开发人员可能不熟悉unix和特定应用服务器等问题
2. 不需要特别的数据库，操作系统和应用服务器专家配合，开发人员自身即可完成。
3. 不需要特别的依赖os和应用服务器，jvm的监测工具。选择自己最熟悉的即可。
4. 开发人员在熟悉这种过程以后，再转到正式的生产环境工作时也更有经验，更容易解决问题。
对测试过程做一点简单介绍。
工具准备：
得益于开源技术的发展，大部分工具都可以免费获得，使用也比较简单。
1. jvm 监控： 对jvm的运行状态进行分析， 可以使用jvm自身带的特性输出日志，结合hp的jmeter profile进行分析。也可以使用jrockit自带的图形化工具mession control。
熟悉什么用什么，越简单越好，目的主要是观察内存堆的变化，线程资源变化，gc情况等。
2. 数据库监控工具： 熟悉数据库的使用数据库自身的特性，不熟悉的可以使用第三方工具，主要目的是观察数据库的锁，连接数信息， 对于db2我比较喜欢使用quest central。 oracle使用OEM或者自身的数据字典已经可以。
3. 应用服务器监控： 主要目的是记录方法的调用情况和执行时间 ，找出频繁调用的方法和执行时间过长的方法。使用jprobe和jprofile都可以很轻松的做到。 如果使用的应用服务器比较偏门，那么可以换一个支持这种检测工具的应用服务器。反正主要目的只是在找问题。
4. sql执行监控：跟踪找出执行时间过长的sql。 我喜欢使用p6spy。
5. 压力工具： jmeter+badboy , 有条件的可以用loadrunner， 和loadrunner近似的还有一个免费的开源产品。 另外web 应用的话， 也可以使用selenium这样的ff扩展来做。微软vs自带的也不错，反正是什么简单用什么。
6. 记录表格： 对问题和资源配置的变更进行记录和对比。
我发现有些人做压力测试，只用压力工具来跑，不肯用各类proile工具来跟踪应用和数据库使用情况，加上经验又不足，结果测来测去都是瞎猜。
设置：
1. 数据库： 如果未使用连接池， 则尽可能的将数据库允许连接设置成最小数字，推荐是从1开始。如果使用连接池，则设置为1.
随着并发模拟数的增加也可以适当上调，但是一定要低于压力工具模拟的并发用户数。数据库环境尽可能接近生产环境，至少要有足够的测试数据。
2. 应用服务器： 对jvm启动堆做最小化设置。比应用服务器要求的最低内存略高，保证应用可以正常启动即可。根据模拟用户数增加可以小步适当上调，但是以保证应用基本运行即可。千万别来大内存。
3. 压力模拟并发数，从1开始逐步往上加。一次加1，2个，上限不要太高，5-10个足以。
步骤
1. 按1用户1连接的方式进行检测
* 找出系统是否存在明显的资源泄露，比如数据库连接，如果存在泄露此种情况下服务器很容易就hold。
* 找出执行时间过长的java方法和sql。进行分析修改。
* 找出那些调用过多的方法和sql，对程序进行分析，看是否做了不必要的调用。 这个问题尤其在使用了第三方包的情况下要小心，我曾经监测出某人写的东西一个方法间接的调用了数据库操作近200次。
有些人做测试喜欢从5以上的数字开始，实在不是什么好习惯，比较明显的问题都容易回避了。
2. 适当增加并发用户，尽可能不调整应用内存，对系统进行长时间的压力测试，比如2-4个小时。 重点观察是否存在内存泄露问题。 内存泄露的问题比较复杂，有时候还依赖于jvm和os，另外有些内存泄露只能在大并发的多线程环境下才会出现。 但是这种测试可以排除掉一些明显的问题，主要是缓存和队列之类的东西。内存泄露一般jvm会有报错和相关的日志dump文件。
3. 逐步增加并发用户和连接数，观察是否存在sql锁 和线程锁的问题。另外并发情况下也可能存在其他一些资源冲突，比如读写文件的情况等等。
线程情况可以使用监控工具观察，比如jrockit带的mc， 也可以直接dump jvm 内存快照找工具分析。
4. 尽可能增加并发用户数，以当前应用能承担的上线进行长时间测试，比如半天到1天，观察是否会存在内存泄露，是否会存在线程资源消耗的问题。也需要检查一下数据库的连接数情况，看是否会一直持续增加，这说明连接池实现有问题，或者设置过大，也可能是jdbc的问题。
5. 其他： 对jvm 可以使用sun和bea的都对比跑一下， 两个实现情况大不同。 jr大并发支持好，所以可能jr上没问题，但是sun的就有问题了。
大部分的问题应该都可以在步骤1，2能得到暴露。在完成了这样的初步测试以后，正式的测试就省心不少了，如果客户有钱，性能不好也可以直接更新硬件了，省事又创造GDP。