Web服务超时的最佳实践

Question

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

是否存在一种常见的最佳实践,例如"从不设计可能需要超过60秒的WS,使用异步令牌模式"

我有兴趣知道你做了什么或你的意见.

Answer 1

这个东西大约30多秒超时是一个荒谬的建议,IMO.你的超时时间应该是3秒左右.是.三.两个之后和四个之前的数字.如果您正在构建基于SOA的应用程序,那么请确保3秒或更短时间.

考虑一下......你的应用程序的用户期望总的响应时间大约为5秒或更短(最好是大约3秒).如果每个单独的服务呼叫需要超过几个*毫秒*才能返回,那么你就会受到冲击.等待30秒以上的服务返回是永恒的.用户永远不会等待那么久.另外,如果你知道它们应该在亚秒级范围内返回,那么等待另外30秒或更长时间来发出错误信号的重点是什么; 它不会在28秒前没有神奇地发挥作用.如果您的应用程序的平均响应时间从一秒钟到超过30秒都有大幅波动,则设计错误.你可能会考虑一些缓存或其他东西.

Answer 2

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

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

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

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