J2EE性能测试与优化技巧(转)
本文的目的是说明如何在典型的J2EE环境下实现可伸缩性测试，性能测试和优化。定义响应时间——从初始的请求到回应下载的完成（刷新整个网页）之间的时间。
负载——系统使用的尺度。当服务器的应用可以承受繁重的通讯量时被称为可以承受“高负载”。
可伸缩性——可伸缩的应用应该拥有随负载线性增长的响应时间。这样的应用可以通过线性的（不是指数性的）增加硬件设施来处理越来越多的数据量。
自动测试工具——通过模拟用户请求网页或在你的网站上遍历预编程的工作流（链接）的工具（如Segue软件的Silk，WebLoad等等）。
负载测试工具——大多数自动测试工具同时也是负载测试工具，如WebLoad。这些工具可以模拟任意数量的用户使用你的站点，并且可以提供重要的分析数据如平均响应时间等。
Profiler（程序刨析器）——Profiler是在你的应用程序运行时进行检测的程序。它能提供你有用的运行时刻信息如特殊代码块的运行时间，内存/堆利用率，内存中特殊对象的实例数目等等。
性能测试的过程
1） 功能测试。大多数应用程序的测试首先是对完成功能的测试。即确保应用程序中所有的测试用例/工作流正常工作。
2） 负载和可伸缩性测试。负载和可伸缩性测试有两种方式：
· 在增加数据库数据量的同时测试响应时间。
· 在增加当前用户数量的同时测试响应时间。
3） 解释结果。在各种数据库容量和不同的负载下测试过响应时间后，就可以在这些测试的平均响应时间和测试中服务器的资源利用率的基础上来做出解释。
4） 优化。在上一步完成后识别出问题所在，然后解释结果并捕捉问题。
负载和可伸缩性测试
负载和可伸缩性测试的目的是确保你的应用程序在使用的高峰时期拥有较好的响应时间。你还可以测试你的应用程序在超载时的行为（因为你的站点的数据库中会有越来越多的数据）。在测试之前，先编写一些脚本，向数据库中填充平均数量的数据，运行性能测试，测量响应时间。然后向数据库中填充大量的数据（大约是三年内可预见数据量的三到四倍），再次运行性能测试。如果第二次测试的响应时间特别长，那么肯定有问题。
在进行性能测试时，你可能会想模拟不同负载下服务器的使用情况。根据经验，可以模拟低负载（1-5并发用户）、中负载（10-50并发用户）、大负载（100并发用户）和重负载（1000以上并发用户）。注意这些数字是不确定的，根据你的商业需求而定。另外，使用负载测试软件模拟10个并发用户并不就真正代表了10个并发用户，因为在负载测试中每个“机器人”在再次命中服务器之前会等待几个毫秒。这样的话，使用负载测试工具模拟10个并发用户差不多代表实际网上冲浪中的30-40个用户。
在测试过了这三种负载级别后，就可以比较在这几种情况下的平均响应时间，考察你的服务器是否可承受大访问量，即平均响应时间是否线性增长。
解释结果
性能测试过程中最有趣的就是解释负载测试的结果。让我们来看看几种不同的可能性：
1． 当数据库的数据量大量增长超过一定程度时，响应时间延长很多。
当数据库中的记录从100行增加到50，000时，响应时间不应该有明显的增加。数据库索引技术使得从表中查找一条记录只需耗费几毫秒的时间，即使该表有成千上万条记录也一样。这就是说，从一个适度数据量的数据库增加到拥有超量数据的数据库时，如果响应时间大大延长，那么你可能还没有索引适当的列。
2． 负载增长时响应时间呈指数化增长
如果在增加并发用户数量时系统变得不可用，那么你的系统就不是可伸缩的。这个结果的解释比较困难，因为问题原因可能是硬件、发布平台的配置、系统体系结构等等。一定要在测试过程中监控以下服务器资源：
1． 监控内存请求。
2． 监控CPU使用情况。
如果CPU是超负荷使用的，就需要更快的或更多的处理器。如果CPU利用率比较低，那么就可能是相关的输入输出问题，检查测试系统的数据库连接、线程数、网络配置等等。
检查过配置，确定不是硬件瓶颈，体系结构和代码都经过了优化，如果问题仍然存在的话，就该进行代码运行时监测了（使用profiler）。
优化
数据库、体系结构、配置和硬件都是需要优化的对象。上面已经提过，导致服务器负荷承受能力低的最简单的失误就是数据库没有经过优化。数据库管理员（DBA）对任何开发组来说都是至关重要的，如果没有的话，可以考虑这样做：
察看所有的EJB，核实数据库没有执行任何编码的SQL语句的线性搜索。可以拷贝代码中的SQL语句到数据库的SQL查询工具窗口中，执行EXPLAIN子句：
Explain select * from table where tablefield = somevalue
尽管Explain的语法根据数据库的不同各有差异，但总有一些东西是相似的。数据库会告诉你该语句是根据索引查询还是线性查询。确保验证了数据库的每一个SQL语句都使用了索引。如果没有使用，建立索引。
优化数据库后再优化硬件配置，下一步再使用profiler优化代码。
Profiler程序在你的应用程序运行时分析它，并提供给你使用其它方法无法得到的信息，如：
1． 每个类在内存中有多少个对象和垃圾收集器的行为。
· 这些信息可以帮助你识别那些类应该被缓存。
· 可以帮助你调整Java内存堆。
2． 应用程序在具体的类中花费了多少时间。
这是非常重要的特征。Profiler可以指出那个类是瓶颈。
有一个这样的profiler程序叫做Optimize-It。Optimize-It可以用于任何Java程序或基于Java的应用服务器。它可以很容易的和WebLogic配置到一起，也可以用来刨析远程服务器上的应用程序。
优化体系结构和具体的项目密不可分。不过其中有一些小的技巧：
1． 确保网络调用最少，特别是数据库调用。
· 一个大的数据库调用比很多小的调用要好得多。
· 确保ejbStore没有为只读操作保存任何信息。
· 使用Details Objects获取Entity Bean状态。
2． 确保在尽可能的情况下利用Cache。
应用服务器可能允许在内存中使用Entity Bean缓存，确保利用了这些特征，因为它可以显著减少数据库调用并加速数据存取。
3． 确保使用Session Bean作为Entity Bean的封装。
可以把一个完整的实例的工作流封装到一个网络调用中，作为一个Session Bean（和一个事务）的一个方法。
结论
应用程序的性能测试与优化是一个挑战。幸运的是，市场上有很多工具可以使这个过程变得简单。使用这些工具按照本文提到的简单步骤，你可以有效的捕获系统的瓶颈所在。 好文章 有水平！！！ 说的很好 ，我只有佩服的 真不错
受益非浅
thanks 太有帮助了,谢谢版主! haha 文章对J2EE的整体测试认识来说有一点帮组但是介绍的不是太详细，反而有些地方很容易误导大家，如其中说到的数据库的优化，并不是数据库建了索引就一定效率高，而是当数据量很大的时候才会效果比较好的 写的很好，顶 学习一下 比较抽象，不是太明白 写的很好 支持一下
值得学习!
值得学习! 好文章，顶一下！ 很棒 佩服的tks
hades
无语 不错
页:
[1]
2
