当可能较慢的操作几乎总是很快时，是否有关于是否使用异步的一般建议？
例如，Redis 调用通常会在一两毫秒内返回，并且几乎总是在 10 毫秒内返回。他们不会的一种情况是如果连接出现问题。然后重试将开始，我们可能会等待几秒钟。
我看到的指导是，当操作可能需要超过 50 毫秒时使用异步，但最好不要在每次调用时产生异步开销，因为异步最多只在 0.1% 的时间内有用。
在这种情况下有通用的策略吗？
在我的特定情况下，我发现 Redis、SQL 和云存储调用在 99% 以上的时间内完成时间小于 20 毫秒，当这些服务暂时不可用时，异常值在 1-60 秒范围内。该应用程序是一个基于 MVC 构建的 Web 服务，每秒处理大约 100 个请求。实际上，每个请求都会使用这些通常快速但可能长时间运行的服务之一。
最佳答案
这将取决于上下文。如果从 ASP 应用程序等程序调用该方法，那么使用该方法通常会非常快，但有时会很耗时，这并不是什么问题。对于繁忙的 Web 服务器来说，罕见的扩展执行造成的性能损失可能比每个快速调用的异步开销问题要小。
但是，如果有一个桌面 UI 应用程序，其中长时间执行将会卡住用户的应用程序，那么这(至少可能是)一个严重的问题，可能比花费一些时间的操作更糟糕每当它通常很慢时，就会延长微秒。在这种情况下，几乎可以肯定异步地完成工作是更好的选择。
所以你必须根据上下文进行分析。如果您知道该方法会很长，为什么要使其异步？会造成什么问题？然后将其与最佳案例运行的执行时间增加几微秒的成本进行比较，看看哪一个对您来说更成问题。
关于c# - 如果操作几乎总是很快完成，是否应该使用异步？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29264052/