最近在对Tomcat服务器的web应用进行性能测试的过程中，有时LoadRunner中总会报错：
Action.c(71): Error -27791: Server "localhost" has shut down the connection prematurely
但是这个错误并不是每次测试都会出现，通常在长时间的测试之后才偶尔出现，而奇怪的是在Tomcat的日志中并没有相应的错误。从出错信息的字面信息来看，应该是服务器由于某些原因关闭了连接，而Tomcat并不认为这是一个错误，因此没有在日志中记录下来。在网上的搜索中看到，这个错误在其他的服务器如WebLogic、IIS等均有发生，看来是一个通用的问题。
在诊断的过程中，发现Tomcat运行界面有时会提示：“ 严重: All threads (10) are currently busy, waiting. Increase maxThreads (10) or check the servlet status ”，根据这一线索对Tomcat的server.xml中的maxThreads、connectionTimeout参数进行配置，解决了这个问题。
试验
为了验证这两个参数对测试结果的影响，我做了一些试验。
测试场景：一个测试脚本、20个虚拟用户、10次迭代
参数设置及相应运行结果：
|
maxThreads |
connectionTimeout （豪秒） |
错误个数 |
|
5 |
1000 |
16 |
|
10 |
1000 |
13 |
|
15 |
1000 |
7 |
|
20 |
1000 |
0 |
|
5 |
10000 |
1 |
|
10 |
10000 |
0 |
|
15 |
10000 |
0 |
|
20 |
10000 |
0 |
试验结论
当最大线程数较少、超时时间较短时，出现这个错误的次数就越多；随着最大线程数逐步接近并发用户数，该错误逐渐减少。另外，延长超时时间也能够减少错误的出现，但这时由于请求在处于排队状态，因此会增加响应时间。
引申
将该结果应用于性能调优中，在一定的负载压力下，增加最大线程数能够有效的提高服务器的并发处理能力，但前提是系统资源如CPU、内存等不会成为系统瓶颈，在不能再提高最大线程数时，也可以用增加超时时间的方法，但这会造成响应时间的增加。参数最佳设置根据具体应用和测试结果而定。在有条件的情况下，最好就是集群了。
附：
当以上错误出现在用到web_reg_save_param函数的响应中时，会伴随着其他错误：
Action.c(248): Error -26377: No match found for the requested parameter "ClientID". Check whether the requested boundaries exist in the response data. Also, if the data you want to save exceeds 10240 bytes, use web_set_max_html_param_len to increase the parameter size
Action.c(248): Error -26374: The above "not found" error(s) may be explained by header and body byte counts being 0 and 0, respectively.
