关于Tsung脚本无法停止的问题

时间:2024-12-21 14:08:09

最近,利用tsung测试cm的时候,脚本是这样配置的:

<load>
28 <arrivalphase phase="1" duration="2" unit="second">
29 <users maxnumber="19" arrivalrate="10" unit="second"></users>
30 </arrivalphase>
31 </load>
32 <options>
33 <option name="global_number" value="13">
34 </options>
35
36 <sessions>
37 <session probability="100" name="raw" type="ts_raw">
38
45 <transaction name="login">
46 <request subst="true">
47 <raw data=" 119 1 %%_sessionID%%&lt;iq>&lt;sessionid>%%_sessionID%%&lt;/sessionid>&lt;login>hanhy,hanhy123&lt;login>&lt;/iq>" ack="local"></raw>
48 </request>
49 </transaction>
50 <for from="1" to="3" incr="1" var="counter">
51 <transaction name="sendmsg">
52 <!--for from="1" to="2" incr="1" var="counter"-->
53 <request subst="true">
54 <raw data=" 124 3 %%_sessionID%%&lt;message>&lt;sessionid>%%_sessionID%%&lt;/sessionid>&lt;content>tsungMsg%%_counter%%&lt;/content>&lt;/message>" ack="local"></raw>
55 </request>
56 <!--thinktime min="2" max="10" random="true"/-->
57 <!--/for-->
58 </transaction>
59 </for>
60
61 <thinktime value="3"/>

也就是说,业务流程是:先登录,登录完以后,发3条消息,然后,在系统驻留3s,脚本结束。但是,执行了一上午脚本却仍然没有结束,此时通过看tsung的log,tsung已经停止了发送,CM也停止了接收与发送消息。首先,我们分析一下脚本没有结束的几种可能:

1、虽然消息发送结束,是否还在thinktime之内

2、脚本里的某个参数设置是不是不误

3、服务端是不是出现了错误

下面,咱们看一下脚本:

先看一下thinktime的设置,thinktime=3,意味着最后一个request在正确处理的情况下,用户在系统内停留3s,用户应该不会有明显的感知。所以,我将问题定位在最后一个请求:

<request subst="true">
54 <raw data=" 124 3 %%_sessionID%%&lt;message>&lt;sessionid>%%_sessionID%%&lt;/sessionid>&lt;content>tsungMsg%%_counter%%&lt;/content>&lt;/message>" ack="global"></raw>
55 </request>

现在看一下这个request中的各个参数,subst是获取动态参数的,剩下的就是ack了,根据Tsung官方的解释:

  • ack="local" as soon as a packet is received from the server, the request is considered as completed. Hence if you use a local ack with a request that do not require a response from the server, it will wait forever (or until a timeout is reached)

每个request中,ack的值均为local,这意味着在这个请求发出以后,一定要等服务器的响应,直到收到响应以后,这个请求才算结束。

Ok,这个暂时可以作为原因之一。再看tsung.dump文件,可以看到

Send:1442885664.692798:<0.90.0>: 119   1             6197146762302455809<iq><sessionid>6197146762302455809</sessionid><login>hanhy,hanhy123<login></iq>
Recv:1442885664.732048:<0.90.0>:<iq><login>1<login></iq>^@
Send:1442885664.733678:<0.90.0>: 124   3             6197146762302455809<message><sessionid>6197146762302455809</sessionid><content>tsungMsg1</content></message>
Recv:1442885664.770652:<0.90.0>:86<message><sessionid>6197146762302455809</sessionid><content>tsungMsg1</content></mes^@
Send:1442885664.772076:<0.90.0>: 124   3             6197146762302455809<message><sessionid>6197146762302455809</sessionid><content>tsungMsg2</content></message>

最后一条消息发出后,始终没有收到 recv。现做如下验证:将ack的值改为no_ack,再运行脚本,果然脚本在数秒内即运行结束。是不是这样就可以解决问题了呢?

也就是说,我们在发出消息后,不管是不是回应,只要成功发送即可。这是不是我们想要的结果?我觉得,如果你要考量事务响应时间这个指标,这样做是不妥的。所以,我们应该追踪一下这个问题,tsung的日志记录是显示发送出去了,但是,服务端究竟收到没有这个请求?那么问题来了,继续抓包!!!进一步验证问题究竟出在哪儿,如果服务端收到请求了,没有给出响应,那么这是服务端的一个bug,如果服务端给出了响应,是tsung没有收到,那么在客户端也开启抓包,继续追踪。