J2EE性能测试（1）

版权声明：本文为博主chszs的原创文章，未经博主允许不得转载。 https://blog.csdn.net/chszs/article/details/1544657

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服务器、网络、路由器和现行的计算机硬件。