是否有任何文章/书籍定义了WS超时的上限设计限制？您是在服务器超时还是推荐客户端特定的超时？
是否有一种常见的最佳做法，例如“从不设计可能需要超过60秒的WS，使用异步令牌模式”
我很想知道你做了什么或你的意见。
答案 0 :(得分：9)
这个大约30多秒超时的东西是荒谬的建议，IMO。你的超时时间应该是3秒左右。是。三。两个之后和四个之前的数字。如果您正在构建基于SOA的应用程序，那么请确保3秒，或 less 。
考虑一下......你的应用程序的用户期望总的响应时间大约为5秒或更短（最好是大约3秒）。如果每个单独的服务呼叫需要超过几个*毫秒*才能返回，那么你就会受到冲击。等待30秒以上的服务返回是永恒的。用户永远不会等待那么久。另外，如果你知道它们应该在亚秒级范围内返回，那么等待另一个 30 或更多秒来发出错误信号的重点是什么;它不会在28秒前没有神奇地发挥作用。如果您的应用程序的平均响应时间从一秒钟到超过30秒都有大幅波动，则设计错误。你可能会考虑一些缓存或其他东西。
答案 1 :(得分：4)
这个问题以及与之相关的问题可能会有所帮助： Is there some industry standard for unacceptable webapp response time?
与您的问题有些相似（没有时间间隔，对不起），但我怀疑对您的工作有用： 超时的常用方法是将它们与“后退”计时器进行平衡 它是这样的： 服务第一次超时，不用担心。 连续第二次服务超时，不要打扰N秒。 连续第三次服务超时，不要在N + 1秒内调用它。 然后是N + 2，N + 3，N + 5，N + 8等，直到达到某个最大限制M。
当您收到有效的回复时，会重置超时计数器。
我正在使用Fibbonacci序列来增加“退避”时间段，但当然你可以使用任何其他合适的功能 - 重点是，如果你正在尝试的服务保持计时你，你“相信“在它变得越来越小，所以你花费更少的资源试图去做它，并且很少敲门。这可能有助于另一端的服务，这可能只是过载而重新请求只会使事情变得更糟，并且它会增加您的响应时间，因为您不会等待一个不太可能回答的服务。
答案 2 :(得分：1)
获取您通过Web服务传输的数据量，了解该过程需要多长时间。
为该号码添加60秒并进行测试。
如果你可以在良好的连接上超时，那么再增加30秒。
冲洗并重复。
答案 3 :(得分：1)
我们通常会对该Web服务采用预期的响应时间（如我们的接口规范中所述）并为其添加30秒。
然后我们在UAT期间监视日志以查看是否存在任何模式（例如，特定数据库调用需要很长时间）并根据需要进行更改。