ASP.NET Web API 2具有Task.Run性能的异步操作方法
我正在尝试使用几个ASP.NET Web API 2.0端点进行基准测试(使用Apache工作台)。 其中一个是同步和一个异步。
[Route("user/{userId}/feeds")] [HttpGet] public IEnumerable GetNewsFeedItemsForUser(string userId) { return _newsFeedService.GetNewsFeedItemsForUser(userId); } [Route("user/{userId}/feeds/async")] [HttpGet] public async Task<IEnumerable> GetNewsFeedItemsForUserAsync(string userId) { return await Task.Run(() => _newsFeedService.GetNewsFeedItemsForUser(userId)); }
在观看Steve Sanderson的演讲之后,我向每个端点发出了以下命令ab -n 100 -c 10 http://localhost....
我很惊讶,因为每个端点的基准测试似乎大致相同。
关闭史蒂夫解释说我期待异步端点更高效,因为它会立即将线程池线程释放回线程池,从而使它们可用于其他请求并提高吞吐量。 但数字看起来完全一样。
我在这里误解了什么?
使用await Task.Run
创建“异步” WebApi是一个坏主意 – 您仍将使用一个线程,甚至来自用于请求的同一线程池 。
这将导致一些不愉快的时刻在这里详细描述:
- 额外(不必要的)线程切换到Task.Run线程池线程。 类似地,当该线程完成请求时,它必须输入请求上下文(这不是实际的线程切换但确实有开销)。
- 创建额外(不必要的)垃圾。 异步编程是一种权衡:您可以以更高的内存使用量为代价来提高响应速度。 在这种情况下,您最终会为完全不必要的异步操作创建更多垃圾。
- Task.Run“意外地”借用线程池线程抛出ASP.NET线程池启发式。 我在这里没有很多经验,但我的直觉告诉我,如果意外任务真的很短,并且如果意外任务持续超过两秒,那么启发式应该很好地恢复。
- ASP.NET无法提前终止请求,即,如果客户端断开连接或请求超时。 在同步的情况下,ASP.NET知道请求线程并可以中止它。 在异步情况下,ASP.NET不知道辅助线程池线程是“for”该请求。 可以通过使用取消令牌来解决此问题,但这不在本博文的范围内。
基本上,您不允许任何与ASP.NET的异步 – 您只需隐藏异步外观后面的CPU绑定同步代码。 Async
本身是I / O绑定代码的理想选择,因为它允许以最高效率利用CPU(线程)(不阻塞I / O),但是当你有Compute绑定代码时,你仍然必须利用它CPU程度相同。
考虑到Task
和上下文切换的额外开销,您将获得比使用简单同步控制器方法更糟糕的结果。
如何使其成为真正的ASYNC:
GetNewsFeedItemsForUser
方法应转为async
。
[Route("user/{userId}/feeds/async")] [HttpGet] public async Task> GetNewsFeedItemsForUserAsync(string userId) { return await _newsFeedService.GetNewsFeedItemsForUser(userId); }
去做吧:
- 如果它是一些库方法,那么寻找它的
async
变体(如果没有 – 运气不好,你将不得不搜索一些竞争模拟)。 - 如果它是使用文件系统或数据库的自定义方法,则利用其异步工具为该方法创建异步API。