这次测试的业务流程很简单，是向tomcat下的一个自制应用加压并观测其性能数据。需求也并不复杂尽量多地对服务器加压，多并发多点击。使用的加压机是3台1U服务器，内存分别为32g，32g，16g。测试机是1台1U服务器，内存硬盘cpu都和加压机相仿。不设置集合点，和思考时间，只自定义一个事务。
需求对于并发用户数的理想为1000以上，每秒点击在10000以上。开始测试后发现，并发数在100以上后，就开始不断报错，错误主要是以下两种
Action.c(10): Error -27796: Failed to connect to server "192.168.12.252:81": [10060] Connection timed out
Action.c(10): Error -27791: Server "192.168.12.252" has shut down the connection prematurely
网上查到的解释是，加压机性能过好，导致端口开的过多并且来不及释放造成的，因此修改了加压机的maxport数和tcptimewaitdelay值。重启后测试，问题明显好转但仍然存在。只要并发用户数超过1000，该报错便源源不断，同时随着报错数的不断增加每秒点击数响应降低。初步判断是服务器端来不及响应部分请求导致很多连接超时。调试了很久找到了解决办法，第一步修改runtime setting下，internet protocol-preferences-options中几个timeout值，强制使lr发起的http请求的超时变长，要修改的值有http-request connect timeout，http-request receive timeout，step download timeout都设置为800秒，顺便提一下，keep-alive http connections应该是http长短连接的设置，由于本次测试的应用均为短连接，所以该值设为no。修改执行加压，报错和点击数仍然形同水火，一个增加另外一个必然减少。反复查看lr的设置后尝试将tools-options-timeout的各个超时也响应增加。加压后，报错再次得到了显著减少。在1000用户数的情况下点击数可以到达每秒20000次并且报错在万分之1的比例。本以为大功告成，谁知场景运行10分钟后，每秒点击数骤然下降，5分钟之后下降到10000，并且仍有下降趋势。抓耳挠腮一阵后，分析出问题也许出在加大报错timeout后，很多非正常连接尚未断开，在800s后渐渐超时，连接数的减少导致请求数减少。尝试勾选runtime setting下general-miscellaneous中error handing的设置continue on error。犹如一弯神器，立竿见影。最终测试结果达到了预期。
顺便提一下，analysis下对于响应时间的分析比较具体，不仅可以看到每次迭代的时间，每个事务的时间，还可以具体到请求和返回的网络消耗时间，服务器响应时间等等，具体可以在average transaction response time图的web page diagnostics中查看，但必须待生成完整日志以后。