转载

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

最近，利用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%%<iq><sessionid>%%_sessionID%%</sessionid><login>hanhy,hanhy123<login></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%%<message><sessionid>%%_sessionID%%</sessionid><content>tsungMsg%%_counter%%</content></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%%<message><sessionid>%%_sessionID%%</sessionid><content>tsungMsg%%_counter%%</content></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没有收到，那么在客户端也开启抓包，继续追踪。

正文到此结束