JMeter在整个负载测试的优越性是毋庸置疑的,它覆盖了常见的各种测试类型,如HTTP, JDBC, JMS 和SOAP。单就Web Service测试,作者做了一个简单的实验,但并没有涉及太多的细节。
试验准备:本地Web Service,运行于JBoss 4.0.3SP1,每个简单请求在4种不同负载下执行5000次,分别是1线程,5线程,10线程和25线程。在SoapUI中为简单起见均使用简单负载策略,并且五执行延时。要分别记录关闭连接和非关闭连接方式的数据。关闭连接方式是指每次请求完毕后关闭连接。反之则是让连接仍然保持打开以等待下个请求,显然会省去很多额外开销。在JMeter中也可以做类似配置,如线程数为1,循环次数5000或线程数25,循环200次。
环境:WinXP SP2, Pentium M 1.8 1 G RAM, JRE 1.5.0_06.
结果:
Threads jmeter soapUI soapUI (*) soapUI cmdline soapUI cmdline (*) 1 8 ms, 105 TPS 6.78 ms, 147 TPS 10.7 ms, 94 TPS 5.75 ms, 174 TPS 10 ms, 99 TPS 5 43 ms, 110 TPS 38.7 ms, 128 TPS 23.7 ms, 211 TPS 30.4 ms, 164 TPS 24 ms, 210 TPS 10 86 ms, 112 TPS 82 ms, 122 TPS 46.5 ms, 215 TPS 61 ms, 164 TPS 38 ms, 262 TPS 25 214 ms, 114 TPS 204 ms, 123 TPS 124 ms, 202 TPS 159 ms, 157 TPS 95 ms, 263 TPS其中带*的是非关闭连接模式下测试的结果。从结果中看出Jmeter的测试值均较SoapUI偏大,但与UI连接关闭模式下执行结果相差无几。实验未给出JMeter命令行下的测试结果。但从经验来讲,命令行执行方式避免了测试工具本身带来的巨大资源消耗,更接近真实值。soapUI在命令行连接不关闭模式下TPS随线程的增加在初期有明显上升的。
从计时机制来看,JMeter 用的是System.currentTimeMillis(),而soapUI用的是更为精确的System.nanoTime().
综上所述(文中没有点明,但这是显而易见的),soapUI在单纯的Web Service 测试时有明显的优势,当要综合其他测试时可以组合使用多种工具。
当然这是soapUI自己做的实验,难免有王婆卖瓜之嫌,有兴趣的朋友可以自己设计实验来测试一下。