TipSearch引擎测试心得

文章来自于老柴开发团队的blog，篇篇皆原创。作者Lucifer为当时部门的测试工程师

 

TipSearch引擎的性能测试刚刚结束，在这次引擎测试上，我们纠结了好久，主要是两个问题：
1.在一个事务中增加了多个请求
对于测试项的理解有误，编辑脚本的时候将多个请求放在了一个事务中，导致测试结果存在很大差异。并没有按照设置的并发数反映对应的性能指标。
总结：
事物——是用户某一步或者某几步操作的集合。当我们需要通过某一步或是某几步操作从而衡量服务器的性能的时候，这时我们把这些操作设置成一个事务。
本次测试应该一个事务中设置一个请求，而不应该将多个请求放在一个事务中。
2.测试过程中发生的失败事物太多
在LR测试过程中错误数太多，错误信息均为：
Action.c(7): Continuing after Error -27796: Failed to connect to server “192.168.18.250:80″: [10048] Address already in use
Try changing the registry value
HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/tcpip/Parameters/TcpTimedWaitDelay to 30
and HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/tcpip/Parameters/MaxUserPort to 65534
and rebooting the machine
See the readme.doc file for more information
客户端的设置均按照错误提示中给出的值来设定，仍然存在大量错误。
原因为：负载生成器的性能太好，发数据包特别快，服务器也响应特别快，从而导致负载生成器的机器的端口在没有timeout之前就全部占满了，即在最后一个端口已经用到，前面已经有端口还没有释放，所以造成了很多请求因为客户端的端口被耗尽无法连接服务器而导致失败，是客户端本身的局限导致，并非引擎问题。
解决办法：
今天又仔细对昨天的结果进行了分析，并做了一些实验，总结如下：
对于此类由于客户端发送的请求太快而出现的问题，可以在Controller的Run-Time Setting中设置Pacing值，即设置每个请求之间的间隔时间（该值可以精确到毫秒）。通过这种方式可以降低单个用户的启动请求速度，同时减少了请求在线程中的驻留时间，这样得到的响应时间的测试结果会更加符合实际。
在本次测试中，将pacing值设置为0.001sec，便可以解决此问题。
From - http://team.mapenjoy.com/?p=79