j2ee性能调优之最小化资源压力测试法则[2]

　　j2ee性能调优之最小化资源压力测试法则[2]   软件测试　

   　我发现有些人做压力测试，只用压力工具来跑，不肯用各类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。

原文转自：http://www.ltesting.net