性能测试是任何分布式或Web应用程序测试计划的重要组成部分。在计划和开发周期中进行性能评价，可以保证交付给客户的应用程序满足客户对于高负载、可用性和可伸缩性的要求。提前确定软件的负载限制可以为适当地进行系统配置提供帮助，从而避免出现意料之外的故障。系统性能分析中要处理的几个问题是:系统或服务器能否处理数百个或数千个客户端的同时请求，以及系统可以处理请求的频率。这种类型的测试不但提供了系统响应时间的绝对度量值，而且针对服务器的回归测试和应用程序代码，检查服务器的响应是否和预期结果相匹配，并为不同供应商的中间件解决方案的评价和比较提供帮助。
Apache JMeter——Apache的性能测试框架，已经广泛地作为Web应用程序的性能测试工具。它可以用于在模拟重负载的条件下分析整个服务器性能。该软件提供了FTP和HTTP请求功能和可扩展自定义脚本功能。本文阐述了Jmeter可用于对Web services进行负载测试的原因。我们特别通过在BEA WebLogic Server 9.0中配置一个简单的Web Services来进行说明。示例测试计划阐述了测试计划的创建、线程组、循环和Web Services请求。我们还讨论了如何测量数据，并通过随附的JMeter图表对图形工具中所显示的结果进行了说明。
JMeter
Apache JMeter是可以对利用HTTP或FTP服务器的应用程序进行测试的工具。它是基于Java的，通过所提供的API它还具有高度可扩展性。典型的JMeter测试包括创建循环和线程组。循环使用预设的延迟来模拟对服务器的连续请求。线程组是为模拟并发负载而设计的。JMeter提供了用户界面。它还公开了API，用户可以从Java应用程序来运行基于JMeter的测试。为了在JMeter中创建负载测试，需要构建测试计划。在实际操作中，Jmeter需要执行一系列的操作。最简单的测试计划通常包括下列元件:
线程组——这些元件用于指定运行的线程数和等候周期。每个线程模拟一个用户，而等候周期用于指定创建全部线程的时间。例如，线程数为5，等候时间为10秒，则创建每个线程之间的时间间隔为2秒。循环数定义了线程的运行时间。使用调度器，还可以设置运行的起始时间。
取样器——对于服务器HTTP、FTP或LDAP请求，这些元件是可配置请求。该教程仅侧重于Web Services请求。
监听器——这些元件用于请求数据的后期处理。例如，可以将数据保存到文件或用图表来说明结果。此时JMeter图表并没有提供许多配置选项;然而它是可扩展的，它始终可以添加额外的可视化效果或数据处理模块。
Apache JMeter网站给出了关于可用元件的详细说明。在某些情况下，如果可用元件不适合特定的测试，开发人员可通过在安装Jmeter的libext目录中放置jar文件来编写他/她自己的脚本或Java类，并将其嵌入测试计划。
本文中我们使用的是版本是JMeter 2.1。从 Web 站点 下载可执行二进制文件，将其解压缩,然后应用程序即可在Windows或Unix平台中使用。如果是在Windows操作系统中工作，要转到bin文件夹用jmeter.bat 或jmeterw.bat启动应用程序。
创建负载测试
使用Jmeter的负载测试功能，可以在服务器上产生高负载并确定其容量和限制。注意:若要使用Web services样本，需要有可用的mail.jar和activation.jar，它们可从Sun Microsystems中获取。由于授权限制，Apache没有分发这些库。下载这两个jar文件之后，将它们放入Java classpath或安装Jmeter的lib目录中。
现在，右键单击Test Plan并添加Thread Group和Loop Controller。我们使用这两个元件来设置模拟的并发用户数和测试持续时间。在树状结构的Loop Controller下面，添加“WebService (SOAP) Request”和Graph，如图2所示。如果不能向测试计划添加WebService请求，则可能是路径中没有mail.jar或activation.jar。
键入线程数、等候周期和循环数。在本教程中我们分别使用5、10和100。将循环控制器计数设置为1。如果配置了Web Services的WebLogic Server仍然没有运行，请手动启动它或从WebLogic Workshop中启动。
配置负载测试
我们需要对发送到服务器的SOAP请求参数进行设置。如果指向WSDL文件的链接(URL)可用，将该链接粘贴到WSDL URL字段并单击Load WSDL。可用的方法将显示在Web Methods组合框中。接下来，需要单击Configure以便填充Server Name或IP、Port Number、Path和SOAPAction。
如果没有可用的WSDL链接，也可以手动键入服务器名称、端口号、路径和SOAP操作的值。最后一步，在SOAP/XML-RPC Data区域填写SOAP请求。用户也可以通过SOAP XML Data选项用File从文件中加载。
输入Web Services请求对话框中的所有字段之后，单击Ctrl+S保存JMeter项目。为了使数据可视化，我们添加了图表元件“Graph results”和“Spline Visualizer”。此外，我们也可以通过添加“Save responses to a file”元件将响应发送到文件;这在检查SOAP响应错误时很有用。为了模拟更真实的客户端请求顺序，我们在树中插入了定时器元件——“Gaussian Random timer”。执行该操作之后，客户端的请求的分布更加混乱，将会以随机方式而不是以相等的时间间隔来点击服务器。我们将Gaussian随机时间设置为偏离100ms，恒定延迟偏移量为300ms.
运行负载测试
用户可以通过单击Ctrl+R运行负载测试，或者从菜单中选择Run并单击Start运行负载测试。单击图形元件，将会看到图表被填充，数据代表对服务器的请求
说明测试结果的图表。线程数=5，等候时间=10，循环数=100。循环控制器设置为1。
我们选择在图表中显示三个参数——吞吐量(绿线)、中间值(紫线)和平均值(蓝线)。我们对测试参数进行修改。为了模拟服务器上的较高负载，我们将线程数提高到10和50并比较服务器的响应时间。再次单击Start并观查图表中显示的结果;参见图5和图6。
说明测试结果的图表。线程数=10，等候时间=5，循环数=100，循环控制器设置为1。
说明测试结果的图表。线程数=50，等候时间=5，循环数=20，循环控制器设置为1
图表底部参数的含义如下:
• 吞吐量是服务器每分钟处理的请求数。
• 平均值是总运行时间除以发送到服务器的请求数。
• 中间值是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。
• 偏离表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。
• 最后的样本就是最后完成的请求。
只要观察这三次运行及它们的相应图表，我们就可以得到下列有价值的结果:
响应时间很明显地随着线程的增加而增加。若要继续进行测试，我们可以更改线程数、等候周期和循环数。注意:我们没有更改或调整服务器的配置。WebLogic Server 9.0中有一个可自动配置的线程池，其配置范围受到限制(请参阅Naresh Revanuru撰写的 Workload Management in WebLogic Server 9.0 ，Dev2Dev)，上表说明客户端数量的增长对服务器响应时间的影响是非线性的。实际上，将这个数字提高两倍或十倍不会产生明显的影响!然而，使用接近或超过默认服务器限制的线程数来运行同一个试验时应引起注意。为了检验从服务器收到的响应是真实的SOAP响应而不是HTTP错误，我们观察下列输出文件的内容。这是符合上面要求的SOAP响应:
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<m:calculateAreaResponse xmlns:m="http://myservice">
<m:return>12</m:return>
</m:calculateAreaResponse>
</soapenv:Body>
</soapenv:Envelope>
为了使测试结果更加可视化，向计划中添加Spline Visualizer，它紧靠着Graph Results。Spline Visualizer提供了关于所有样本次数的视图。它用分段插入功能绘制出一条连续的线，在绘制时跨越10个点，每个点代表10﹪的样本。在样条图表中用直线取代连接点，提供了基于多项式近似算法的平滑分布视图。
Multiple JMeters
JMeter还具有一项十分有用的Remote Start功能，它允许用户从多台机器启动JMeter测试。客户端主机地址可以输入到位于bin文件夹下的“jmeter.properties”文件中。找到remote_hosts属性并在那里添加远程主机名称，使用逗号进行分隔。重新启动Jmeter，在Run菜单中单击Remote Start或Remote Start All。某些Web和应用程序服务器可连续处理同一个IP地址的多个请求以及并行处理不同IP地址的请求，因此，对于请求来自不同的机器或将测试负载分布到几个客户端显得十分关键的情况，可以使用该选项来执行操作。
其他功能
前面已经提到，Jmeter包含HTTP、FTP和 LDAP取样器。创建这些请求是一项简单的任务，Jmeter用户手册中作了详细说明;它通常包括创建Thread Group、添加取样器、定时器和监听器。下面我们介绍一些有关这些标准取样器之外的、可能需要一些非标准配置步骤的功能。
脚本
特别支持Java请求和BeanShell脚本的自定义测试和脚本是JMeter的另一个功能，它为负载测试开发人员提供了更大的灵活性。我们可以创建脚本化测试并将其作为一个Java类进行编译，然后将其传递给JMeter运行。为了使用BeanShell脚本功能，需要下载BeanShell jar并将其放置在/lib目录下面，以便JMeter在运行时可以选取它。用户可以使用Java取样器中的beanshell API，或者创建BeanShell取样器，由它读取文件中的脚本或处理文本框中所键入的命令。下面的代码样本说明了添加到HTTP取样器中的BeanShell断言。用户可以对基于HTTP请求的响应的测试执行过程进行分析和控制。一个好的方案应该创建具有线程组的测试计划，并在计划的时间循环启动负载测试。请求将点击Web服务器并获得其响应。
print("HTTP return code is:" + ResponseCode);
print("HTTP return message is:" + ResponseMessage);
if (SampleResult.isSuccessful())
{
print("Success");
SampleResult.setStopTest(true);
SampleResult.setStopThread(true);
}
响应可用添加到测试计划的BeanShell断言进行记录，它紧靠着HTTP取样器，如果Web服务器响应与某个条件相匹配，也就是说，如果成功或包含了预期的字符串，则脚本会停止测试或线程，否则将继续执行。
JMS应用程序
为了使用JMeter对JMS应用程序进行负载测试，要下载ActiveMQ jar并将其复制到/lib目录。根据前面的测试，我们首先创建线程组，并添加JMS Point-to-Point样本。JMS Point-to-Point对话框需要填写下列参数:QueueConnection Factory、JNDI Name Request队列和JNDI Name Receive队列。例如，我们可以使用WebLogic示例服务器上安装的JMS模块中的参数;在这种情况下，它们为weblogic.examples.jms.QueueConnectionFactory和weblogic.examples.jms.exampleQueue。我们也可以创建自定义的JMS连接工厂和队列。对于WebLogic服务器，我们还需要添加 weblogic.jndi.WLInitialContextFactory作为初始Context Factory值和Provider URL，通常情况下，其形式为:t3://hostname:7001，例如:t3://localhost:7001。
自定义取样器
许多测试人员迟早会面临下面这个问题:假如必须要创建测试计划，而JMeter没有提供必需的取样器或监听器。例如，用户需要测试Enterprise JavaBeans应用程序。用户仍然可以使用JMeter的Java Request，它实质上是Java类，可以向其添加需要的任何逻辑。我们创建一个样本Java取样器，它将向应用程序服务器发送请求并调用会话bean。首先，我们创建package mytest和称为JBTest.javaJava的Java类:
package mytest;
import mybeans.LoginBeanRemoteHome;
import mybeans.LoginBeanRemote;
import java.io.Serializable;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import java.util.Hashtable;
import javax.naming.*;
import javax.rmi.*;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import org.apache.jmeter.protocol.java.sampler.*;
import org.apache.jmeter.config.Arguments;
import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient;
import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext;
import org.apache.jmeter.samplers.SampleResult;
import org.apache.jmeter.testelement.TestElement;
public class EJBTest implements JavaSamplerClient ,
Serializable {
public EJBTest() {
}
public void setupTest(JavaSamplerContext context) {
}
public Arguments getDefaultParameters() {
Arguments params = new Arguments();
return params;
}
public SampleResult runTest(JavaSamplerContext context) {
SampleResult results = new SampleResult();
try{
Context env = getInitialContext("t3://localhost:7001");
LoginBeanRemoteHome home = (LoginBeanRemoteHome)
PortableRemoteObject.narrow(
env.lookup("ejb.LoginBeanRemoteHome"),
LoginBeanRemoteHome.class);
LoginBeanRemote bean = (LoginBeanRemote) home.create();
bean.login("TestUser","TestPassword");
results.setSuccessful(true);
}
catch (NamingException ne){
ne.printStackTrace();
results.setSuccessful(false);
}
catch (RemoteException re){
re.printStackTrace();
results.setSuccessful(false);
}
catch (CreateException ce){
ce.printStackTrace();
results.setSuccessful(false);
}
return results;
}
static Context getInitialContext(String url) throws NamingException {
Hashtable env = new Hashtable<String,String>();
env.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, url);
return new InitialContext(env);
}
public void teardownTest(JavaSamplerContext context) {
}
}
为了使用该代码，要对它进行编译以创建jar文件myEJBTest.jar，将jar复制到JMeter classpath(如lib目录)，或者将classpath位置添加到jmeter.properties 文件——其形式为:
user.classpath=d:jakarta-jmeter-2.1.1libextmyEJBTest.jar
重新启动JMeter，向测试计划添加Java Request元件，并从下拉菜单中选择mytest.EJBTest。缺省情况下，JMeter提供的是“SleepTest”和“JavaTest”。现在，我们可以向测试计划添加线程组、循环和监听器并运行测试计划。
测试数据库
Jmeter所支持的另一个功能是评价数据库服务器的性能。用户可以使用软件提供的JDBC Request元件，也可以使用脚本或Java类来创建自己的测试。例如，使用一些与前面类似的示例可以测试存储过程的调用。许多数据库优化技术都可以使用，包括使用特定供应商优化(如查询的并行处理)，使用联结或索引。此外，当用多个boolean评价创建查询时，数据组织知识很有用。在处理大量数据时，应用程序中的数据库和查询优化是特别关键的，JMeter是一个可以在这类评价中提供某些评测的工具。例如，可以在数据或查询优化前后执行性能或负载测试并对结果进行比较。
我们通过创建MySQL实例的测试计划来演示样本数据库性能测量计划是如何工作的。首先，从MySQL网站下载JDBC驱动程序，并复制到/lib目录以便JMeter可以访问数据库。现在启动JMeter，创建线程组，并设置循环数和相应的线程数。添加JDBC Connection Configuration、JDBC Query Defaults和JDBC Request元件。在这些对话框中，我们需要配置数据库连接和查询。输入数据库URL值，它们的形式类似于:jdbc:mysql://hostname/databaseName，然后为JDBC Driver Class输入com.mysql.jdbc.Driver。针对这个试验，我们创建了数据库customers，它带有包含下列三个字段的customer表格:名称、地址和帐户。在Query框中键入查询，例如，从客户中选择名称。
为了使结果可视化，可以添加带有响应时间的图表，或者，如果要检验响应是否匹配特定模式，可以添加响应断言。例如，在Response Assertion中添加文本模式“Smith”。在Assertion Result窗口将显示如“Test failed, text expected to contain /Smith/”之类的错误，或者，如果由于设置错误而没有连接，则显示“Response was null”。如果测试成功，将不返回任何内容。除了图表和断言监听器，我们还可以使用Aggregate Report，它以表格的形式显示样本数、平均值、中间值和吞吐量的摘要。
结束语
使用JMeter现有的功能和它所提供的用户界面，可以模拟5个并发线程，以10和5 ms延迟点击服务器。本教程说明了该工具能够用于对Web services的响应时间进行测量的原理。例如，利用JMeter脚本，可以查找客户端的身份认证和授权。所测试的应用程序服务器和JMeter客户端都本地安装在同一个工作站，然而同样的设置也可以用于测试远程服务器。
所得到的结果和图表还不能提供有价值的性能报告;它们只能说明WebLogic Server对Web Services请求响应时间的简单分布。要了解是否实现了优化，应当在优化前后针对两个不同的服务器，或针对客户端线程变量数的不同负载来运行相同的负载测试。换句话说，只有比较的结果才具有实用价值，它能够帮助了解服务器性能，进而基于这些评测做出判断。