J2EE性能测试（1）
1、问题：
1）应用程序的运行有多快？
2）它将适用于多大的规模？
3）应用程序服务器的性能是什么？
2、The Grinder的负载生成/数据收集工具
The Grinder是一个基于Java的工具。
3、J2EE性能测试
1）性能测试一个完整的应用程序；
2）性能设计——分析J2EE API不同方面的性能代价，以及某种设计决策对总体性能的影响。
性能依赖于应用程序以及性能的确切含义。
J2EE是一组广泛的API，甚至一个相对简单的J2EE应用程序都可以以多种方式编写。
前端：有一组JSP和servlet处理与终端用户或客户端的通信，或是将访问委托给一个实体bean；
前端可使用JDBC与数据库通信；
开发人员可选择让该前端调用一个无状态的会话bean；
然后该无状态的会话bean使用JDBC API与数据库通信，或者是将该访问委托给一个实体bean；
实体bean可以使用容器管理的持久性（Container-Managed Persistence，CMP）或者是Bean管理的持久性（Bean-Managed Persistence，BMP）等。
4、获取清晰的真实的有关性能的答案的唯一方法是，在你自己的特定环境中亲自测试它。
1）交互式应用程序：性能一般是通过大小和规划问题的容量来定义，如应用程序能够处理的同时发生的用户数量。
从终端用户的角度看，关键的性能属性是响应时间。
响应时间直接受到同时与应用程序交互的用户数的影响。
随着用户负载的增加，测试应该指出工作繁忙的硬件系统组件，可反过来告知如何在应用程序服务器、数据库服务器和网络之间最佳的分割硬件预算资源。
该信息还能够帮助确定最优的部署配置。
前端（servlet和JSP）可以运行在一个应用程序服务器上，而事务逻辑（EJB、JMS队列）运行在另一个服务器上。
2）后端应用程序
当应用程序的主要接口是面向用户时，基于响应时间和用户数的性能陈述是有意义的；当应用程序具有与另一个系统的接口时，需要：
吞吐量来衡量。
表达吞吐量性能最流行的方式之一是每秒的事务处理（Transactions per Second，TPS）。
使用吞吐量必须清楚地说明了上下文。
在研究servlet时，我们定义事务处理为一个请求——因此吞吐量是servlet在一个设定的时间周期内（一秒）执行的同样请求的数量。
当分析JMS时，吞吐量就是消息（message）。
注意：吞吐量不是一个速度测度，而是一个容量（capacity）测度。
吞吐量并不总是提供应用程序性能的完整描述。
5、上下文测试方法
1）基准测试（Benchmarking）：是在各种不同的环境和工作负载下记录应用程序性能的过程；
2）轮廓（Profiling）：涉及到精确地调查应用程序将大部分计算周期花费在什么地方，以及应用程序如何高效地使用系统资源；
3）调整（Tuning）：测试、基准测试和轮廓都反馈给调整过程，后者是优化应用程序和环境获取最大性能的过程；
6、基准测试
ORACLE数据库——轮廓工具SQL_TRACE和TKPROF；
WEBLOGIC服务器——WEBLOGIC控制台查看起内部情况；
J2EE应用程序——Introscope和JProbe轮廓工具来帮助准确查明应用程序中组件级的瓶颈。
7、调整
一个典型的J2EE应用程序将建立在一个应用程序服务器的基础上，此外，还有数据库、Java虚拟机（JVM）、操作系统、TCP/IP堆栈、Web服务器、网络、路由器和现行的计算机硬件。
