我已经接管了一个现有的 MVC 网站，该网站使用实体框架和 hangfire，托管在 Azure 上并使用 Azure 数据库。网站每隔一段时间就会超时。
我是 Azure 门户、实体框架和hangfire 的新手。
如果我增加 DTU，它会清除超时问题吗？
我正在寻找如何诊断网站超时原因的方法。我使用 elmah 添加了错误日志记录并检查了hangfire，但这并没有给我任何进一步的信息。
Azure 门户中有什么可以提供帮助的吗？
【问题讨论】：
标签： entity-framework azure hangfire azureportal
如果它“超时”并且如果“增加 DTU 解决超时”并且这些观察结果是正确的（我认为你必须真正说服自己这是绝对正确的，不要轻易做出这个假设）然后通常和明显候选人是“一个缓慢的 sql 查询”。 Entity Framework 常与 linq 一起使用，无需编写 sql 即可创建 sql 查询。这些查询通常适用于非常简单的任务，例如 someData.Where(x=>x.Id == 1).First()，但是，如果使用 linq 连接表，或者创建复杂的关联，生成的 sql 可以从性能的角度来看，变得非常糟糕。您可以添加日志以写出 linq 生成的 sql，或者您可以尝试跟踪数据库以查看其上运行的 sql。如果无法进行跟踪，您仍然可以使用元查询来查看缓存查询计划等内容，SQL Server 可以为您提供估计成本和缓存执行次数。
您仍然可以在不使用 linq 的情况下上吊自己。您仍然可以将存储过程与 EF 一起使用。太多的开发人员对 SQL 性能感到天真仍然；你需要梳理你的后端并学习模式、存储过程；检查所有内容的sql内容。检查任何数据库触发器（容易错过）。危险信号是子查询、太多的连接、太多的查询结果、查询中的大量字符串操作、在字符串上连接表或基于 XML/JSON 的 SQL 工作。
请注意，当负载高时，“慢 sql 查询”会变慢。当缓慢的 sql 查询建立起来时，它们只需要更多的时间来解决。这也可能导致削弱表锁定，具体取决于查询的性质。
但是查询可以是高效的，但仍然会导致锁定。即一个表经常被写入，它阻塞了该表的其他写入或读取。这有点难以诊断，但您可以通过仔细检查数据库调用日志及其执行时间来弄清楚。您还可以在数据库上运行 sql 查询来诊断长时间运行的查询，或者在给定时间点锁定哪些表。
最后，检查您的应用程序的任何后端网络作业。如果超时发生在重复发生的日期或时间，那么某人的批处理 SQL 可能会阻止读取您的生产数据库。
但这都是猜测。我认为你需要做更多的研究来确定究竟是什么导致网站变得无响应。如果您可以记录常见查询的响应时间，则可以排除基于 SQL 的延迟是否是罪魁祸首，并从那里开始工作。您指定的任何技术本质上都没有“错误”。
如果查询是高性能的，但仍然会导致问题，一个长期的解决方案是添加消息队列之类的东西并智能地批处理你的 sql 工作，或者只是让数据库异步工作而不阻塞 UI。
您应该将任何记录的超时与 azure 的监控相关联。 Azure 可以在仪表板上为您提供 CPU/RAM/页面访问等。
【讨论】：
SQL Azure 有点不同。它不具备专用数据库的按需性能，除非您准备投入大量资金。即便如此......
EF，如果写得很好，可以表现得很好。如果写得不好，它可能是一条狗，而这些问题在 SQL Azure 这样的平台上更加复杂。
首先检查您的 EF 上下文是否设置为使用适合 Azure 的执行策略：https://docs.microsoft.com/en-us/ef/ef6/fundamentals/connection-resiliency/retry-logic
接下来是看看可以在 Azure 上运行哪些类型的 SQL 跟踪。跟踪对于了解 EF 在幕后所做的工作至关重要。我不熟悉可用于 Azure 的工具，在我的情况下，我的 Azure 经验是在 VM 上运行 SQL Server，因为 SQL Azure 太不成熟，当时不符合 HIPAA，而且我们能够获得的 DTU 估计值昂贵。在最坏的情况下，您能否将数据库备份恢复到 SQL Server 实例中，并将应用程序环境的副本临时指向该实例以运行常见的使用场景？使用 SQL 跟踪，您可以准确了解 EF 执行查询的时间和频率，以及它正在执行的查询。
看点：
.Select() 可用于减少数据量。甚至可能加载与显示/完成的内容无关的整组实体的情况，例如有人在执行.Count() 或.Any() 或执行@ 之前使用.ToList() 的情况987654326@ 只是为了进行!= null 检查。使用 EF 和其他 ORM 开发的常见错误归结为“拉得太多、太频繁”。令人惊讶的是，与我合作过的许多客户的开发团队都没有使用分析器来检查他们的 ORM 使用效率。 （到目前为止，我说的是 0%。）
【讨论】：