一般采用两种解决办法:
第一种就是程序尽量规避这种等待时间过长的请求,采用异步的方式实现。
第二种就是修改server配置:
IHS的确有自动重发参数,默认是60秒,IBM网站上也找到了说明
Recommended value =
(number of appservers in cluster - 1) x (absolute ServerIOTimeout) - 1
For example, if there are two appservers in the cluster, and the value of ServerIOTimeout is -60, then the maximum RetryInterval setting would be:
(2 - 1) x (60) - 1 = 59 seconds or less
Another example, if there are four appservers in the cluster, and the value of ServerIOTimeout is -60, then the maximum RetryInterval setting would be:
(4 - 1) x (60) -1 = 179 seconds or less
Warning: Setting RetryInterval to a value higher than the recommended maximum, based on the formula above, can lead to an undesirable situation where all of the appservers in the cluster may be marked down simultaneously resulting in all requests temporarily failing.
如果与某个服务器的连接发生故障,插件就会将该服务器标记为暂时不可用。虽然缺省值是 60 秒,但您可能必须减小此值以便提高重负载情况下的吞吐量。如果已将 IBM HTTP Server 配置为对每个进程使用少于 10 个线程,那么减小 RetryInterval 值可能有益。
减小 RetryInterval 对吞吐量有何影响?当特定应用程序服务器的线程忙于处理其他连接(重负载条件下的情况)时,如果插件尝试连接到该应用程序服务器,该连接可能会超时,从而导致插件将该服务器标记为暂时不可用。如果同一插件进程对同一服务器打开了其他连接,并且在其中一个这些连接上接收到响应,就会再次标记该服务器。如果每个 IBM HTTP Server 进程只有几个线程,那么可能尚未对此应用程序服务器建立连接。在这种情况下,插件必须等待完整的重试时间间隔。 注: 尽管减小 RetryInterval 可以提高性能,但如果所有应用程序服务器都在运行中,那么当某个应用程序服务器当机时,较小的值会对性能产生负面影响。在这种情况下,每个 IBM HTTP Server 进程都会更频繁地尝试进行连接并失败,从而导致等待时间延长和整体吞吐量下降。