当一个潜在的慢速操作几乎一直很快时，是否有关于是否使用异步的一般建议？
例如，Redis调用通常会在一毫秒或两秒内返回，几乎总是在10毫秒内。如果连接出现问题，他们不会遇到的一种情况。然后重试将开始，我们可能会等待几秒钟。
我看到的指导是当操作可能花费超过50毫秒时使用异步，但是如果它在每次调用时仅产生0.1％的时间，则不会产生异步开销。
是否有在这种情况下使用的一般策略？
在我的特定情况下，我看到Redis，SQL和云存储调用在<20ms 99 +％的时间内完成，当这些服务暂时不可用时，异常值在1-60秒范围内。该应用程序是一个基于MVC构建的Web服务，每秒可处理大约100个请求。实际上，每个请求都使用这些通常快速但可能长期运行的服务之一。
答案 0 :(得分：2)
这将取决于背景。如果从ASP应用程序调用该方法，那么该方法通常非常快，但偶尔耗时，并不是真正的问题。对于繁忙的Web服务器而言，从罕见的扩展执行中丢失的性能可能不是每次单个调用的异步开销很快就会出现问题。
但是，如果有一个桌面UI应用程序，其中长时间执行将冻结用户的应用程序，这（至少可能）是一个严重的问题，可能比采取一些操作更糟糕的操作每当通常很慢时，微秒就会更长。在这种情况下，几乎可以肯定的是，异步地完成这项工作。
所以你必须根据上下文进行分析。如果你知道方法会很长，为什么要让它异步;会引起什么问题？然后将其与在最佳案例运行的执行时间中添加几微秒的成本进行比较，看看哪个更适合您。