【发布时间】：2010-09-20 22:40:41
【问题描述】：
是否有任何文章/书籍定义了 WS 超时的上限设计限制？您是否在服务器超时或也建议客户端特定超时？
是否有常见的最佳实践，例如“永远不要设计可能需要超过 60 秒的 WS，使用异步令牌模式”
我也有兴趣了解您的工作或您的意见。
【问题讨论】：
标签： wcf web-services timeout scalability
【发布时间】：2010-09-20 22:40:41
【问题描述】：
IMO，关于 30 多秒超时的内容是荒谬的建议。您的超时时间应约为 3 秒。是的。三。两个之后和四个之前的数字。如果您正在构建基于 SOA 的应用程序，那么肯定需要 3 秒，或者更少。
想一想...您的应用程序的用户期望总响应时间约为 5 秒或更短（最好约为 3 秒）。如果每个单独的服务呼叫都需要超过几毫秒*才能返回，那么您就完蛋了。等待一项服务返回 30 多秒是永恒的。用户永远不会等待那么久。另外，如果您知道它们应该在不到一秒的范围内返回，那么等待另外 30 秒或更长时间以发出错误信号的意义何在？它不会在 28 秒前没有的地方神奇地工作。如果您的应用程序的平均响应时间从不到 1 秒到超过 30 秒出现剧烈波动，则说明设计不正确。您可能会考虑一些缓存或其他东西。
【讨论】：
-
它可以是应用服务器之间的服务，与最终用户无关。
-
有趣，@Robert 你是怎么得出这个数字的：3 秒？
-
这个建议似乎很滑稽。用户当然希望得到快速响应，但是在 3 秒内得到错误回复真的比在 20 秒内得到有效答案更好吗？设计快速响应和选择客户端超时不是一回事。
-
在 20 秒内获得有效响应没有用处，因为用户已经离开了。请参阅 Amazon 在这方面的工作 RE：用户等待 UI 呈现多长时间。
-
我想我们都同意快速响应是首选，并且您的系统应该设计为快速返回数据，但我也同意尼克的推理。作为用户，我很乐意迟到总比不到好。
这个问题以及与它的答案相关的问题可能会有所帮助： Is there some industry standard for unacceptable webapp response time?
与您的问题有些相干（没有时间间隔，抱歉），但我怀疑对您的工作有用：
一种常见的超时方法是使用“退避”计时器来平衡它们。
它是这样的：
服务第一次超时，不用担心。
连续第二次服务超时，不要费心调用它 N 秒。
连续第三次服务超时，N+1秒不要调用。
然后是 N+2、N+3、N+5、N+8 等，直到达到某个最大限制 M。
当您收到有效响应时，超时计数器会重置。
我在这里使用斐波那契数列来增加“退避”时间段，但您当然可以使用任何其他合适的功能——关键是，如果您尝试的服务不断为您计时，您“相信“它变得越来越小，因此您花费更少的资源试图到达它，并且更少敲门。这可能有助于另一端的服务，它可能只是超载和重新请求只会让事情变得更糟，并且它会增加您的响应时间，因为您不会等待不太可能回答的服务。
【讨论】：
-
采用几何级数而不是线性级数（例如 N、2N、4N）更为常见——以防止服务器被锤击。
-
在第一次重试之后添加一个随机数量也是很常见的，这样停机的服务就不会被同时重试的所有内容破坏。
获取您通过网络服务传输的数据量，看看该过程需要多长时间。
将该数字加上 60 秒并进行测试。
如果你可以让它在良好的连接上超时，那么再增加 30 秒。
冲洗并重复。
【讨论】：
我们通常采用该 Web 服务的预期响应时间（如我们的接口规范中所述）并增加 30 秒。
然后我们在 UAT 期间监控日志以查看是否有任何模式（例如，特定的数据库调用需要很长时间）并酌情进行更改。
【讨论】：