wcf - Web 服务超时的最佳实践

Question

是否有任何文章/书籍定义了 WS 超时的上限设计限制？你是在服务器超时还是推荐客户端特定的超时？

是否有一个常见的最佳实践，例如“永远不要设计可能需要超过 60 秒的 WS，使用异步令牌模式”

我也有兴趣了解您的工作或您的意见。

Answer 1

IMO，大约 30 秒以上的超时是荒谬的建议。您的超时时间应约为 3 秒。是的。三。两个之后和四个之前的数字。如果您正在构建基于 SOA 的应用程序，那么肯定需要 3 秒或更短的时间。

想一想……您的应用程序的用户期望总响应时间约为 5 秒或更短（最好约为 3 秒）。如果每个单独的服务呼叫都需要超过几毫秒* 才能返回，那么您就完蛋了。等待一项服务返回 30 多秒是永恒的。用户永远不会等待那么久。另外，如果您知道它们应该在不到一秒的范围内返回，那么再等待30秒或更长时间以发出错误信号的意义何在？它不会在 28 秒前没有的地方神奇地工作。如果您的应用程序的平均响应时间从不到 1 秒到超过 30 秒出现剧烈波动，则说明设计不正确。您可能会考虑一些缓存或其他东西。

Answer 2

这个问题以及与它的答案相关的问题可能会有所帮助： 对于不可接受的 webapp 响应时间是否有一些行业标准？

与您的问题有些相切（没有时间间隔，抱歉），但我怀疑对您的工作很有用：超时的一种常见方法是用“退避”计时器来平衡它们。
它是这样的：第一次服务超时，不用担心。连续第二次服务超时，不要费心调用它 N 秒。连续第三次服务超时，N+1秒不要调用。然后是 N+2、N+3、N+5、N+8 等，直到达到某个最大极限 M。

当您获得有效响应时，超时计数器会重置。

我在这里使用斐波那契数列来增加“退避”时间段，但当然您可以使用任何其他合适的功能——关键是，如果您尝试的服务不断为您计时，您“相信”它变得越来越小，因此您花费更少的资源试图到达它，并且更少地敲门。这可能有助于另一端的服务，它可能只是超载和重新请求只会让事情变得更糟，并且它会增加您的响应时间，因为您不会等待不太可能回答的服务。

Answer 3

获取您通过 Web 服务传输的数据量，看看该过程需要多长时间。

将 60 秒添加到该数字并进行测试。

如果你可以让它在良好的连接上超时，那么再增加 30 秒。

冲洗并重复。

Answer 4

我们通常采用该 Web 服务的预期响应时间（如我们的接口规范中所述）并增加 30 秒。

然后我们在 UAT 期间监视日志以查看是否有任何模式（例如，特定的 DB 调用需要很长时间）并酌情进行更改。