有没有一篇文章/书籍定义了WS超时的上限设计限制？您是否会在服务器上超时或建议客户端设置特定的超时时间？
是否有常见的最佳实践，例如“永远不要设计超过60秒的WS，使用异步令牌模式”？
我很想知道您的做法或意见。
4个回答
17
关于超过30秒的超时建议是荒谬的，我的看法是应该设置大约3秒的超时时间，是的，三秒。在2和4之间的数字。如果您正在构建基于SOA的应用程序，则应该设定小于或等于3秒的超时时间。
想想看...你的应用程序用户期望总响应时间不超过五秒钟(最好是三秒钟)。如果每个单独的服务调用需要超过几毫秒才能返回，那就太慢了。等待30多秒仅仅为了让一个服务返回是漫长的。用户永远不会等那么久。此外，如果您知道它们应该在小于一秒的时间范围内返回，等待另外30秒或更长时间来表示错误条件有什么意义呢？它不会像28秒前那样自动变得正常。如果您的应用程序平均响应时间从小于一秒到超过30秒波动很大，说明设计有误。您可以考虑使用一些缓存策略等方法。
- Robert C. Barth
8
11这可以是应用服务器之间的服务，与最终用户没有太大关系。 - MMind
1有趣的问题，@Robert 你是怎么得出那个3秒的数字的？ - DanielV
5这个建议似乎有些轻率。当然，用户期望快速响应，但是在3秒钟内收到一个错误信息真的比在20秒钟内收到有效答案更好吗？设计迅速响应和选择客户端超时并不是一回事。 - Nick
1在20秒内获得有效的响应是没有用的，因为用户已经离开了。请参考亚马逊在这个领域的工作，即用户等待UI渲染的时间。 - Robert C. Barth
3我认为我们都同意快速响应更好，你的系统应该设计成能够快速返回数据，但我也同意Nick的推理。作为用户，能够收到晚一点但仍然有回应，我也会感到满意。 - Adam Davis
显示剩余3条评论
10
这个问题以及与其答案中链接的内容可能会有所帮助:
是否存在不可接受的Web应用程序响应时间的行业标准？
与您的问题有些不相关（没有时间间隔，抱歉），但我认为对您的工作很有用：
一种常见的超时处理方法是将其与“退避”计时器平衡。
它大致如下： 第一次服务超时，不要担心。 连续第二次服务超时，N秒内不再调用它。 连续第三次服务超时，N+1秒内不再调用它。 然后是N+2，N+3，N+5，N+8等，直到达到某个最大限制M。 当您获得有效响应时，超时计数器将被重置。 在此处，我使用了Fibbonacci序列来增加“退避”时间段，但当然您可以使用任何其他合适的函数。重点是，如果您一直被超时的服务，您对它的信任会越来越小，因此您会花费更少的资源尝试连接它，而且访问频率也会变得更低。这可能有助于另一端的服务，因为该服务可能只是负载过重，重新请求只会使情况变得更糟，并且它将增加您的响应时间，因为您不会在等待一个不太可能回应的服务。
它大致如下： 第一次服务超时，不要担心。 连续第二次服务超时，N秒内不再调用它。 连续第三次服务超时，N+1秒内不再调用它。 然后是N+2，N+3，N+5，N+8等，直到达到某个最大限制M。 当您获得有效响应时，超时计数器将被重置。 在此处，我使用了Fibbonacci序列来增加“退避”时间段，但当然您可以使用任何其他合适的函数。重点是，如果您一直被超时的服务，您对它的信任会越来越小，因此您会花费更少的资源尝试连接它，而且访问频率也会变得更低。这可能有助于另一端的服务，因为该服务可能只是负载过重，重新请求只会使情况变得更糟，并且它将增加您的响应时间，因为您不会在等待一个不太可能回应的服务。
- Dmitriy
2
通常使用等比数列而不是等差数列（例如N，2N，4N），以防止服务器过载。 - ashes999
3通常在第一次重试之后，会为每次重试添加一个随机量，这样就不会出现所有请求同时重试而导致服务崩溃的情况。 - Robert C. Barth
2
计算通过您的Web服务传输的数据量并查看该过程需要多长时间。
将该数字加60秒进行测试。
如果您可以在良好的连接上使其超时，则再添加30秒。
反复执行以上步骤。
- mugafuga
2
我们通常会将网络服务的预期响应时间（如接口规范所述）加上30秒。
然后在用户验收测试期间监控日志，以查看是否存在任何模式（例如特定的数据库调用需要较长时间），并进行相应的更改。
然后在用户验收测试期间监控日志，以查看是否存在任何模式（例如特定的数据库调用需要较长时间），并进行相应的更改。
- nzpcmad
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接