性能测试loadrunner场景问题之socket

2.2 Socket场景问题

2.21在场景执行中，异步交易socket连接中断，同步交易正常进行。

在bancs稳定性测试中遇到过该问题，经过检查并不是系统出现故障导致服务中断，而是loadrunner种场景设置的问题。由于分端口进行测试异步脚本分成了四个，在流水号取值时必须唯一，然而在场景设置中我们用了很大的数据表示流水，用随机的方式取参，本以为不会重复，但问题还是出现了，修改为固定取值时，该问题解决了。

这个问题虽然是在特定的场合出现，但是在其他类似场景中参数取值时要慎重考虑。可以采取固定取值或者分块取值。

2.22长连接与短连接对场景的影响

1.长连接

Client方与Server方先建立通讯连接，连接建立后不断开， 然后再进行报文发送和接收。

2.短连接

Client方与Server每进行一次报文收发交易时才进行通讯连 接，交易完毕后立即断开连接。此种方式常用于一点对多点 通讯，比如多个Client连接一个Server.

一般WEB网站的http服务都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用短连接，同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

在bancs测试中脚本里设置的长连接在压力较大的情况下会出现这样的问题：假如一支交易的接收报文是可变长的，这样会影响脚本执行的效率，为了简便我们只需要截取接收报文里面的某些可以确定交易成功的信息就可以了，其它的可以不要，这就造成了第二笔交易因接收到第一笔交易的剩余报文而报错的现象。改为短连接后每次连接都会初始化配置，这就解决了报文接收错误的问题。

2.23 在外围测试中查看后台日志发现交易总是少一笔。

解决办法：通过查看，发现是由于异步交易，只发不收，最后一笔发完还没来得及处理socket连接就已结束，在socket连接断开前设置一个thinktime就解决了。