JMeter在WebServices性能测试中的应用

JMeter在WebServices性能测试中的应用性能测试是任何分布式或Web应用程序测试计划的重要组成部分。在计划和开发周期中进行性能评价，可以保证交付给客户的应用程序满足客户对于高负载、可用性和可伸缩性的要求。提前确定软件的负载限制可以为适当地进行系统配置提供帮助，从而避免出现意料之外的故障。系统性能分析中要处理的几个问题是：系统或服务器能否处理数百个或数千个客户端的同时请求，以及系统可以处理请求的频率。这种类型的测试不但提供了系统响应时间的绝对度量值，而且针对服务器的回归测试和应用程序代码，检查服务器的响应是否和预期结果相匹配，并为不同供应商的中间件解决方案的评价和比较提供帮助。ApacheJMeter——Apache的性能测试框架，已经广泛地作为Web应用程序的性能测试工具。它可以用于在模拟重负载的条件下分析整个服务器性能。该软件提供了FTP和HTTP请求功能和可扩展自定义脚本功能。本文阐述了Jmeter可用于对Webservices进行负载测试的原因。我们特别通过在BEAWebLogicServer9.0中配置一个简单的WebServices来进行说明。示例测试计划阐述了测试计划的创建、线程组、循环和WebServices请求。我们还讨论了如何测量数据，并通过随附的JMeter图表对图形工具中所显示的结果进行了说明。JMeterApacheJMeter是可以对利用HTTP或FTP服务器的应用程序进行测试的工具。它是基于Java的，通过所提供的API它还具有高度可扩展性。典型的JMeter测试包括创建循环和线程组。循环使用预设的延迟来模拟对服务器的连续请求。线程组是为模拟并发负载而设计的。JMeter提供了用户界面。它还公开了API，用户可以从Java应用程序来运行基于JMeter的测试。为了在JMeter中创建负载测试，需要构建测试计划。在实际操作中，Jmeter需要执行一系列的操作。最简单的测试计划通常包括下列元件：线程组——这些元件用于指定运行的线程数和等候周期。每个线程模拟一个用户，而等候周期用于指定创建全部线程的时间。例如，线程数为5，等候时间为10秒，则创建每个线程之间的时间间隔为2秒。循环数定义了线程的运行时间。使用调度器，还可以设置运行的起始时间。取样器——对于服务器HTTP、FTP或LDAP请求，这些元件是可配置请求。该教程仅侧重于WebServices请求。监听器——这些元件用于请求数据的后期处理。例如，可以将数据保存到文件或用图表来说明结果。此时JMeter图表并没有提供许多配置选项；然而它是可扩展的，它始终可以添加额外的可视化效果或数据处理模块。ApacheJMeter网站给出了关于可用元件的详细说明。在某些情况下，如果可用元件不适合特定的测试，开发人员可通过在安装Jmeter的\lib\ext\目录中放置jar文件来编写他/她自己的脚本或Java类，并将其嵌入测试计划。本文中我们使用的是版本是JMeter2.1。从Web站点下载可执行二进制文件，将其解压缩,然后应用程序即可在Windows或Unix平台中使用。如果是在Windows操作系统中工作，要转到bin文件夹用jmeter.bat或jmeterw.bat启动应用程序。初始用户界面如图1所示。图1：启动ApacheJMeter创建负载测试使用Jmeter的负载测试功能，可以在服务器上产生高负载并确定其容量和限制。注意：若要使用Webservices样本，需要有可用的mail.jar和activation.jar，它们可从SunMicrosystems中获取（请参阅下面的链接）。由于授权限制，Apache没有分发这些库。下载这两个jar文件之后，将它们放入Javaclasspath或安装Jmeter的lib目录中。图2：创建线程组和基本WebServices测试计划现在，右键单击TestPlan并添加ThreadGroup和LoopController。我们使用这两个元件来设置模拟的并发用户数和测试持续时间。在树状结构的LoopController下面，添加“WebService(SOAP)Request”和Graph，如图2所示。如果不能向测试计划添加WebService请求，则可能是路径中没有mail.jar或activation.jar。键入线程数、等候周期和循环数。在本教程中我们分别使用5、10和100。将循环控制器计数设置为1。如果配置了WebServices的WebLogicServer仍然没有运行，请手动启动它或从WebLogicWorkshop中启动。配置负载测试如图3所示，我们需要对发送到服务器的SOAP请求参数进行设置。如果指向WSDL文件的链接（URL)可用，将该链接粘贴到WSDLURL字段并单击LoadWSDL。可用的方法将显示在WebMethods组合框中。接下来，需要单击Configure以便填充ServerName或IP、PortNumber、Path和SOAPAction。图3：WebService（SOAP）请求对话框（单击图像查看完整尺寸的屏幕截图）如果没有可用的WSDL链接，也可以手动键入服务器名称、端口号、路径和SOAP操作的值。最后一步，在SOAP/XML-RPCData区域填写SOAP请求。用户也可以通过SOAPXMLData选项用File从文件中加载。输入WebServices请求对话框中的所有字段之后，单击Ctrl+S保存JMeter项目。为了使数据可视化，我们添加了图表元件“Graphresults”和“SplineVisualizer”。此外，我们也可以通过添加“Saveresponsestoafile”元件将响应发送到文件；这在检查SOAP响应错误时很有用。为了模拟更真实的客户端请求顺序，我们在树中插入了定时器元件——“GaussianRandomtimer”。执行该操作之后，客户端的请求的分布更加混乱，将会以随机方式而不是以相等的时间间隔来点击服务器。我们将Gaussian随机时间设置为偏离100ms，恒定延迟偏移量为300ms.运行负载测试用户可以通过单击Ctrl+R运行负载测试，或者从菜单中选择Run并单击Start运行负载测试。单击图形元件，将会看到图表被填充，数据代表对服务器的请求，如图4至6所示。图4：说明测试结果的图表。线程数＝5，等候时间＝10，循环数＝100。循环控制器设置为1（单击图像查看完整尺寸的屏幕截图）。我们选择在图表中显示三个参数——吞吐量（绿线）、中间值（紫线）和平均值（蓝线）。我们对测试参数进行修改。为了模拟服务器上的较高负载，我们将线程数提高到10和50并比较服务器的响应时间。再次单击Start并观查图表中显示的结果；参见图5和图6。图5：说明测试结果的图表。线程数＝10，等候时间＝5，循环数＝100，循环控制器设置为1（单击图像查看完整尺寸的屏幕截图）。图6：说明测试结果的图表。线程数＝50，等候时间＝5，循环数＝20，循环控制器设置为1（单击图像查看完整尺寸的屏幕截图）图表底部参数的含义如下：吞吐量是服务器每分钟处理的请求数。平均值是总运行时间除以发送到服务器的请求数。中间值是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。偏离表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。最后的样本就是最后完成的请求。只要观察这三次运行及它们的相应图表，我们就可以得到下列有价值的结果：线程数吞吐量，响应/分钟平均值，ms中间值，ms573130321013753830503479115100响应时间很明显地随着线程的增加而增加。若要继续进行测试，我们可以更改线程数、等候周期和循环数。注意：我们没有更改或调整服务器的配置。WebLogicServer9.0中有一个可自动配置的线程池，其配置范围受到限制（请参阅NareshRevanuru撰写的WorkloadManagementinWebLogicServer9.0，Dev2Dev），上表说明客户端数量的增长对服务器响应时间的影响是非线性的。实际上，将这个数字提高两倍或十倍不会产生明显的影响！然而，使用接近或超过默认服务器限制的线程数来运行同一个试验时应引起注意。为了检验从服务器收到的响应是真实的SOAP响应而不是HTTP错误，我们观察下列输出文件的内容。这是符合上面要求的SOAP响应：soapenv:Envelopexmlns:soapenv=:Header/soapenv:Bodym:calculateAreaResponsexmlns:m=:return/m:calculateAreaResponse/soapenv:Body/soapenv:Envelope为了使测试结果更加可视化，向计划中添加SplineVisualizer，它紧靠着GraphResults。SplineVisualizer提供了关于所有样本次数的视图。它用分段插入功能绘制出一条连续的线，在绘制时跨越10个点，每个点代表10﹪的样本。在样条图表中用直线取代连接点，提供了基于多项式近似算法的平滑分布视图。结果如图7所示图7：使用SplineVisualizer说明与图6相同测试结果的图表（单击图像查看完整尺寸的屏幕截图）MultipleJMetersJMeter还具有一项十分有用的RemoteStart功能，它允许用户从多台机器启动JMeter测试。客户端主机地址可以输入到位于bin文件夹下的“jmeter.properties”文件中。找到remote_hosts属性并在那里添加远程主机名称，使用逗号进行分隔。重新启动Jmeter，在Run菜单中单击RemoteStart或RemoteStartAll。某些Web和应用程序服务器可连续处理同一个IP地址的多个请求以及并行处理不同IP地址的请求，因此，对于请求来自不同的机器或将测试负载分布到几个客户端显得十分关键的情况，可以使用该选项来执行操作。其他功能前面已经提到，Jmeter包含HTTP、FTP和LDAP取样器。创建这些请求是一项简单的任务，Jmeter用户手册中作了详细说明；它通常包括创建ThreadGroup、添加取样器、定时器和监听器。下面我们介绍一些有关这些标准取样器之外的、可能需要一些非标准配置步骤的功能。脚本特别支持Java请求和BeanShell脚本的自定义测试和脚本是JMeter的另一个功能，它为负载测试开发人员提供了更大的灵活性。我们可以创建脚本化测试并将其作为一个Java类进行编译，然后将其传递给JMeter运行。为了使用BeanShell脚本功能，需要下载BeanShelljar并将其放置在/lib目录下面，以便JMeter在运行时可以选取它。用户可以使用Java取样器中的beanshellAPI，或者创建BeanShell取样器，由它读取文件中的脚本或处理文本框中所键入的命令。下面的代码样本说明了添加到HTTP取样器中的BeanShell断言。用户可以对基于HTTP请求的响应的测试执行过程进行分析和控制。一个好的方案应该创建具有线程组的测试计划，并在计划的时间循环启动负载测试。请求将点击Web服务器并获得其响应。print(HTTPreturncodeis:+ResponseCode);print(HTTPreturnmessageis:+ResponseMessage);if(SampleResult.isSuccessful()){print(Success);SampleResult.setStopTest(true);SampleResult.setStopThread(true);}响应可用添加到测试计划的BeanShell断言进行记录，它紧靠着HTTP取样器，如果Web服务器响应与某个条件