entity-framework - Azure 数据库、EF、超时问题

Question

我已经接管了一个现有的 MVC 网站，它使用实体框架和hangfire，托管在 Azure 上并使用 Azure 数据库。网站经常超时。

我是 Azure 门户、实体框架和hangfire 的新手。

如果我增加 DTU，它会清除超时问题吗？

我正在寻找如何诊断网站超时原因的方法。我已经使用 elmah 添加了错误日志记录并检查了hangfire，但这并没有给我任何进一步的信息。

azure 门户中有什么可以提供帮助的吗？

标签： entity-frameworkazurehangfireazureportal

Answer 1

如果它“超时”并且如果“增加 DTU 解决超时”并且这些观察结果是正确的（我认为你必须真正说服自己这是绝对正确的，不要轻易做出这个假设），那么通常和明显的候选人是“一个缓慢的 sql 查询”。Entity Framework 常与 linq 一起使用，无需编写 sql 即可创建 sql 查询。这些查询通常适用于非常简单的任务，例如 someData.Where(x=>x.Id == 1).First()，但是，如果使用 linq 连接表，或者创建复杂的关联，生成的 sql 可以从性能的角度来看，变得非常糟糕。您可以添加日志以写出 linq 生成的 sql，也可以尝试跟踪数据库以查看其上运行的 sql。如果无法追踪，

您仍然可以在不使用 linq 的情况下上吊自己。您仍然可以将存储过程与 EF 一起使用。太多的开发人员对 SQL 性能仍然天真；你需要梳理你的后端并学习模式、存储过程；检查所有内容的sql内容。检查任何数据库触发器（容易错过）。危险信号是子查询、太多的连接、太多的查询结果、查询中的大量字符串操作、字符串上的连接表或基于 XML/JSON 的 SQL 工作。

请注意，当负载高时，“慢 sql 查询”会变慢。当缓慢的 sql 查询建立起来时，它们只需要更多的时间来解决。这也可能导致削弱表锁定，具体取决于查询的性质。

但是查询可以是高性能的，但仍然会导致锁定。即一个表经常被写入，它阻塞了该表的其他写入或读取。这有点难以诊断，但您可以通过仔细检查数据库调用日志以及它们执行所需的时间来弄清楚。您还可以在数据库上运行 sql 查询来诊断长时间运行的查询，或者在给定时间点锁定哪些表。

最后，检查您的应用程序的任何后端网络作业。如果超时发生在重复发生的日期或时间，那么某人的批处理 SQL 可能会阻止您的生产数据库被读取。

但这都是猜测。我认为你需要做更多的研究来确定究竟是什么导致网站变得无响应。如果您可以记录常见查询的响应时间，则可以排除基于 SQL 的延迟是否是罪魁祸首，并从那里开始工作。您指定的任何技术本质上都没有“错误”。

如果查询是高性能的，但仍然会导致问题，一个长期的解决方案是添加消息队列之类的东西并智能地批处理你的 sql 工作，或者只是让数据库异步工作而不阻塞 UI。

您应该将任何记录的超时与 azure 的监控相关联。Azure 可以在仪表板上为您提供 CPU/RAM/页面访问等。