为什么超时值太小？

Question

我不确定这是否是一个纯粹的计算器相关问题。这与一般的设计实践有关。因为我无法想到另一个相关的堆栈交换站点，所以在这里发布它。

在将异步调用转换为同步调用的一般设计实践中，我们使用超时并等待结果。虽然从响应的角度来看，这可能不是一个好的做法，但它确实使执行更容易。

我见过很多这样的实现，并且经常注意到开发人员往往会给出非常小的超时值。我可以理解，当他们这样做时，人们可能需要一个响应系统。但是我看到的很多这些应用程序都非常关键，数据丢失非常严重。因此，等待更多并试图获得尽可能多的数据总是更好，而不是提前超时并向用户发出错误消息。现在，服务器无法提供数据或客户端无法访问服务器等情况很少发生。在这些情况下，我预计这种等待会有很长一段时间。毕竟，这些暂停并不意味着等待一定会持续到给定的超时值;超时值只是一个上限。所以，我一直在争论更高的价值。但是我发现在越来越多的地方使用低值，现在我感到困惑，如果这种做法中还有别的东西我不明白。

所以，我的问题是：除了需要响应以实现等待的非常短的超时之外，是否有任何争论？

Answer 1

一如既往，正确的决定取决于现实生活中的数据。 超时时间应与通常成功完成操作所需的时间成比例。

例如，发送UDP消息可能需要1到50毫秒，所以100毫秒的超时比合理更合理，但通过网络复制文件可能需要几分钟或更长时间，因此100毫秒超时是可笑的。

短期和长期超时都有优点和缺点，所以这是一个折衷。如上所述，更长的超时使用更多的资源（任务，线程，内存等）来完成相同数量的工作，而短暂超时可能会导致数据丢失。

总之，您需要设置一个可配置的超时，这听起来合理，然后确定是否在生产中暂停了太多操作或者相反地进行校准。