loadrunner 微信项目压测问题总结1

微信重构项目今天终于要压测啦，首先压测的是商品详情页，脚本如下：

脚本中num参数化见链接：https://www.cnblogs.com/meixiaoqiu/articles/10120235.html

场景设置如下：

runtime-setting设置为：不打印日志、不下载资源、忽略思考时间

压测过程中发现第二个请求的TPS为0，第一个请求TPS很低，出现很多27796的错误，查询网上的解释是：客户端性能比较好，发出压力太快，所以把tcp/ip的连接或端口占满。

客户端 使用 netstat -ano 命令查看客户端端口占用情况，发现确实有很多tcp状态为 time_wait ，所以基本可以验证确实是客户端性能太好，把端口占满了，导致其他VU连接不上。

解决办法：

1、通过让每次迭代不启用新的连接，就可以解决此问题。操作如下，在controller的运行时设置中的-->browser Emulation-->不扣选simulate a new user on each iteration，这样运行时并发人数是多少，那么就启动多少个端口。

去掉这个选项的意思是，始终使用一个tcp/ip链接，不断开，也就是开发人员所说的长链接或持久连接。   
短连接：建立连接-----发送和接收报文1-------关闭连接

长连接：建立连接-----发送和接收报文1.。。。2.。。。3-----关闭连接 】

勾选这个选项就一定会报27796错误么？

2、回答上面的提问，答案是不一定。如果你每次迭代启用新的端口，但是由于迭代次数*并发数<65534就不会报这个错误。如果设置的迭代次数*并发数>65534，也不一定会出现这个错误，例如：并发人数为1000,平均响应时间为1s，那么也就是说1s会占用1000个端口，也就是说不到66s时端口就会占满，如果服务器能在65s内关闭之前占用的端口之间的连接，也就是说65s超时时间，或者会话保持为65s以内，那么就能解决此问题。

27796 错误解决的参考链接：https://blog.csdn.net/niqinwen/article/details/17302631/

按照1中的方法重新设置runtime-setting ，然后进行压测，发现TPS确实升高了好多，说明之前确实是客户端的端口被占满导致的TPS 降低。