最近，利用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没有收到，那么在客户端也开启抓包，继续追踪。