This stuff about 30+ second timeouts is ridiculous advice, IMO. Your timeouts should be about 3 seconds. Yes. Three. The number after two and before four. If you're building an application based on a SOA, then DEFINITELY 3 seconds, or less.
Think about it... the user of your app expects a TOTAL response time of about five seconds or less (preferably about three). If EACH INDIVIDUAL SERVICE CALL is taking more than a couple of* milliseconds* to return, you're hosed. Waiting 30+ seconds for ONE service to return is an eternity. The user will never wait around that long. Plus, if you know they're supposed to return in the sub-one second range, what's the point of waiting for another 30 or more seconds to signal an error condition; it's not going to magically work where when it didn't 28 seconds ago. If your application has wild swings in average response time from sub-one second to over 30 seconds, something was designed incorrectly. You might think about some caching or something.
Somewhat tangential to your question (no time intervals, sorry), but I suspect useful for your work: A common approach to timeouts is to balance them with "back-off" timers. It goes something like this: The first time a service times out, don't worry about it. The second time in a row a service times out, don't bother calling it for N seconds. The third time in a row a service times out, don't call it for N+1 seconds. Then N+2, N+3, N+5, N+8, etc, until you reach some maximum limit M.
The timeout counter is reset when you get a valid response.
I am using a Fibbonacci sequence to increase the "back-off" time period here, but of course you can use any other suitable function -- the point being, if the service you are trying keeps timing you, you "belief" in it get smaller and smaller, so you spend fewer resources trying to get to it, and knock on the door more rarely. This might help the service on the other end, which could simply be overloaded and re-requesting just makes matters worse, and it will increase your response time since you won't be waiting around for a service that is unlikely to answer.
发布评论
评论（4）
在我看来，这个关于 30 秒以上超时的建议是荒谬的。 你的超时时间应该是大约 3 秒。 是的。 三。 二之后和四之前的数字。 如果您正在构建基于 SOA 的应用程序，那么肯定需要 3 秒，或者更少。
想想看......您的应用程序的用户期望总响应时间约为五秒或更短（最好约为三秒）。 如果每个单独的服务呼叫都需要超过几毫秒*的时间才能返回，那么您就完蛋了。 等待一项服务返回 30 秒以上就像永恒。 用户永远不会等待那么久。 另外，如果您知道它们应该在不到一秒的范围内返回，那么再等待 30 秒或更长时间来发出错误条件信号有什么意义？ 28 秒前它不会神奇地起作用。 如果您的应用程序的平均响应时间从不到一秒到超过 30 秒大幅波动，则说明某些部分设计不正确。 您可能会考虑一些缓存或其他东西。
This stuff about 30+ second timeouts is ridiculous advice, IMO. Your timeouts should be about 3 seconds. Yes. Three. The number after two and before four. If you're building an application based on a SOA, then DEFINITELY 3 seconds, or less.
Think about it... the user of your app expects a TOTAL response time of about five seconds or less (preferably about three). If EACH INDIVIDUAL SERVICE CALL is taking more than a couple of* milliseconds* to return, you're hosed. Waiting 30+ seconds for ONE service to return is an eternity. The user will never wait around that long. Plus, if you know they're supposed to return in the sub-one second range, what's the point of waiting for another 30 or more seconds to signal an error condition; it's not going to magically work where when it didn't 28 seconds ago. If your application has wild swings in average response time from sub-one second to over 30 seconds, something was designed incorrectly. You might think about some caching or something.
这个问题以及与其答案相关的问题可能会有所帮助：
对于不可接受的 Web 应用程序响应时间是否存在某种行业标准？< /a>
与你的问题有点相切（没有时间间隔，抱歉），但我怀疑对你的工作有用：
处理超时的常见方法是使用“退避”计时器来平衡超时。
事情是这样的：
服务第一次超时时，不用担心。
连续第二次服务超时，N秒就不用再调用了。
服务连续第三次超时，N+1秒内不要调用。
然后 N+2、N+3、N+5、N+8 等，直到达到某个最大限制 M。
当您获得有效响应时，超时计数器将重置。
我在这里使用斐波那契数列来增加“退避”时间段，但当然您可以使用任何其他合适的函数 - 重点是，如果您尝试的服务不断为您计时，您就会“相信”它变得越来越小，所以你花费更少的资源来尝试到达它，并且更少敲门。 这可能有助于另一端的服务，该服务可能会过载，重新请求只会使情况变得更糟，并且它会增加您的响应时间，因为您不会等待不太可能响应的服务。
This question, and the ones linked to in answers to it, might help:
Is there some industry standard for unacceptable webapp response time?
Somewhat tangential to your question (no time intervals, sorry), but I suspect useful for your work:
A common approach to timeouts is to balance them with "back-off" timers.
It goes something like this:
The first time a service times out, don't worry about it.
The second time in a row a service times out, don't bother calling it for N seconds.
The third time in a row a service times out, don't call it for N+1 seconds.
Then N+2, N+3, N+5, N+8, etc, until you reach some maximum limit M.
The timeout counter is reset when you get a valid response.
I am using a Fibbonacci sequence to increase the "back-off" time period here, but of course you can use any other suitable function -- the point being, if the service you are trying keeps timing you, you "belief" in it get smaller and smaller, so you spend fewer resources trying to get to it, and knock on the door more rarely. This might help the service on the other end, which could simply be overloaded and re-requesting just makes matters worse, and it will increase your response time since you won't be waiting around for a service that is unlikely to answer.
获取您通过网络服务传输的数据量，看看该过程需要多长时间。
在该数字上添加 60 秒并进行测试。
如果您可以在良好的连接上使其超时，则再添加 30 秒。
冲洗并重复。
Take the amount of data you are transfering via your web service an see how long the process takes.
Add 60 secs to that number and test.
If you can get it to timeout on a good connection then add 30 more seconds.
rinse and repeat.
我们通常会采用该 Web 服务的预期响应时间（如我们的接口规范中所述）并增加 30 秒。
然后，我们在 UAT 期间监视日志以查看是否存在任何模式（例如，特定的数据库调用需要很长时间）并进行适当的更改。
We generally take the expected response time for that web-service (as documented in our interface specification) and add 30 seconds to it.
Then we monitor the logs during UAT to see if there are any patterns (e.g. specific DB calls taking a long time) and alter as appropriate.