迁移到azure

Question

将我的应用程序部署到Azure后，我遇到了几个数据库密集型报告的SQL超时问题。

我已经尝试在连接字符串中更改sql超时但没有任何影响..我也尝试将数据库从S2升级到P1，然后执行得很好，不会超时..但不幸的是，这不是真的我们的选择。

如何更改这些操作的超时值？

这是我收到的错误（之前没有发生在rackspace上）

  

＆＃39; /＆＃39;中的服务器错误应用

     

等待操作超时

     

描述：执行期间发生了未处理的异常   当前的网络请求。请查看堆栈跟踪了解更多信息   有关错误的信息以及它在代码中的起源。

     

异常详细信息：System.ComponentModel.Win32Exception：等待   操作超时

     

来源错误：

     

执行期间生成了未处理的异常   当前的网络请求。有关的来源和位置的信息   可以使用下面的异常堆栈跟踪来识别异常。

     

堆栈追踪：

     

[Win32Exception（0x80004005）：等待操作超时]

     

[SqlException（0x80131904）：执行超时已过期。超时   在完成操作或服务器之前经过的时间段   没有回应。]   System.Data.SqlClient.SqlConnection.OnError（SqlException异常，   Boolean breakConnection，Action 1 wrapCloseInAction）+2442634
  System.Data.SqlClient.SqlInternalConnection.OnError（SQLEXCEPTION   exception，Boolean breakConnection，Action 1 wrapCloseInAction）   5766568

Answer 1

如果您将计划从低级更改为更大级并且它可以正常运行，那么这肯定是性能问题。

Azure SQL使用DTU来衡量您使用CPU，IO等的资源数量。因此，如果您使用100％的DTU，您的查询会有所延迟，使用100％会延长您将获得超时异常，因为默认情况下.net连接中有30秒超时。增加可能对您没有帮助，因为问题可能是您多次运行相同的查询并且它开始相互阻塞。

转到您的数据库，然后查询Performance Insight，并查看您的热门查询运行时间。并从那里开始优化。

潜在的地方可能是EntityFramework Include，如果您正在使用它，这可能会生成大量数据要返回的查询，从而减慢查询速度并使用大量IO。

如果您仍想增加超时，可以通过添加

在.config file中为连接字符串执行此操作

;Connection Timeout=60

但正如我所说的那种50/50修复它可以工作，但更好的是看看哪些查询很慢并改进它们

PS。我最近在我的应用程序中遇到了同样的问题，有一个特殊的查询我永远不会说会使用这么多的DTU。

PS。好吧，我第一次没有正确地阅读你的问题。所以我删除了我以前的答案

Answer 2

正如Volodymyr指出的那样，我绝对会关注优化超时中涉及的查询。但我也想指出......

  

SQLAzure不会为我们更新索引/统计信息，就像onpremises ..你必须要照顾它..

在我们的案例中，我们创建了每周重建索引并每周更新统计数据的任务，然后与超时相关的错误降至99％。

对于仍在超时的查询，我们采取了优化它们的方法

Answer 3

截至本月（2019年4月），同一期杂志出人意料地出现。我们已经准备好将S3（标准3）发布到我们的应用程序中，然后突然出现零件查询不起作用。

使用Visual Studio进行调试以查找“我们的错误”表明，所有查询都已超时。我发现这篇文章指出必须超过最大DTU。

我以为'啊哈！ ...这可能是因为我复制了数据库，并且不得不多次运行数据插入查询才能更新该数据库。否。只需阅读查找内容即可。

我们现在所处的

S3，最近被更改为“标准”，微软认为这是“典型的IO工作负载”。从DTU的使用情况来看，我们为0.7％。不可能将查询超时时间强制设置为30秒或更短。

好的，Premium现在适用于“更多的IO密集型工作负载”。好像之前的DTU使用量的0.7％是IO密集型的。

我将其更改为P0和Bingo！零件查询再次运行。

如果这能使我们赚更多的钱，我会称呼它为我们的力量。昨天我花了很多时间解决这个问题，所以我不想让其他人有同样的经历。