最近，我的带有 Entity Framework 6.1 服务器的 Web Api 2 上的 Web 请求速度急剧下降。向所有查询数据库的请求添加 ~5000ms。在过去的三天里，我一直在绞尽脑汁想弄明白。
设置:
- 网络 API 2.2
- Entity Framework 6.1.1
- 用于 IoC 的 Autofac，DbContext 是 InstancePerLifetimeScope() 以及其他所有内容。
- 一个自定义 HttpParameterBinding，用于从访问 token 中获取实体 ID。这会查询数据库。
- 只有一个DelegatingHandler，用于记录请求
我做了什么:
- 预生成的 View ，略有改进
- 我们查询的实体中的属性减少，没有改善
- 关闭 AutoTrackChanges，没有改善
- 针对许多请求尝试了 AsNoTracking()，但没有改善
- 使用 Ant Performance Profiler 进行分析，没什么用
- 使用 SQL Management Studio 分析数据库，查询速度很快
为什么我说处理程序和 Controller 之间存在延迟？我在 Controller 操作的开始和结束时用 DateTime.Now 计时，1745ms 日志记录处理程序在 await base.SendAsync(request, cancellationToken) 之前和之后执行时间，6234ms 。我也为绑定(bind)计时，只有 2 毫秒。
那是 4489ms 的时间未被计算在内。其他请求也有类似的时间安排。它发生在日志记录处理程序获取请求并报告它之后但在绑定(bind)开始之前。那里发生了什么？它来自哪里？我们没有任何分拆出来的 async void 方法，我们没有任何应该花费那么长时间的每个请求操作。完全难住了。
编辑:重复相同的请求不会提高性能。我不认为一次命中性能是问题所在，它一直很差。
最佳答案
感谢您的帮助，我最终找到了答案。
我们有被注入(inject) Controller 的服务，它们的构造函数使用潜在的异步调用来预加载一些东西。将其更改为使用 AsyncLazy 是解决方案。
现在列举对那些处于类似情况的人可能有用的步骤。
玩过棋盘游戏猜猜谁？这与调试非常相似。您想提出的问题会减少一半的潜在问题。不要以“是不是我觉得很脏的特定方法”开始，而是以:
- 什么有效，什么无效？找到差异。这就是你的问题集。
- 使用通用问题缩小问题集。找到共同的相似之处并摆脱它们。是异步调用吗？ (感谢评论者)这是死锁之类的东西吗？ (再次感谢)。是第一次点击还是初始加载？
- 一旦您删除了共同的相似之处，就可以开始注释掉代码了。我将其缩小到一个构造函数，该构造函数被注入(inject)了三个对象并且它自己没有做任何工作。当不是前两个对象时，我知道我的问题出在哪里!
关于c# - Web Api 2 Controller 和处理程序之间有五秒的延迟，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26558455/