SQL Azure Premium层一次不可用超过一分钟，如果是这样，我们的利用率约为10-20％

Question

我们运行的网络服务在高峰时段每分钟获得6k +请求，在非工作时间每分钟获得大约3k请求。从第三方Web服务和自定义生成的图像编译的大量数据馈送。我们的服务和代码已经成熟，我们已经运行了多年。优秀开发人员的大量工作已经进入我们服务的代码库。

我们正在迁移到Azure，我们发现了一些严重的问题。首先，我们看到我们的Premium P1 SQL Azure数据库通常会在整整1-2分钟内无法使用。对不起，这看起来很荒谬。我们如何运行Web服务，请求等待2分钟才能访问我们的数据库？这种情况每天发生几次。从标准级别切换到高级级别后，它发生的次数减少了，但是我们的数据库的DTU容量已经接近我们，并且我们经常受到严重限制。

我们的SQL Azure数据库是Premium P1，根据新的Azure门户，我们的负载通常低于20％，每小时有几个峰值达到50-75％。当然，我们甚至不能信任Azure的门户网站指标。旧门户网站没有为我们的SQL提供任何数据，并且新门户网站有时显然是错误的（我们的数据库没有停机1/2小时，如图表所示，但它已经停机超过2分钟） ：

Azure报告我们的数据库大小略高于12GB（在我们自己的SQL Server安装中，数据库低于1GB - 这是许多问题中的另一个，为什么在Azure上报告为12GB？）。多年来我们做了很多调整，并且有很好的指数。

我们的服务在两个D4云服务实例上运行。我们的DB库都在实现重试逻辑，在完全失败之前等待2,4,8,16,32和48秒。控制器都是异步的，我们的大多数外部服务调用都是异步的。数据库访问仍然主要是同步的，但我们最重的查询是异步的。我们大量使用内存和Redis缓存。最频繁使用我们的数据库是为每个请求插入1-3条记录（这些表每10分钟仅查询一次以检查错误级别）。

除了批量处理这些请求日志记录插件之外，我们的应用程序的db访问代码实际上并没有多少给出。我们在这个数据库上的DTU分配还远远不够，我们的数据库所在的服务器就像2000 DTU可以分配一样。如果我们每天必须忍受超过1分钟的不可用时间，我们就会放弃Azure。

这是我们得到的最好的吗？

查询数据库中的统计数据似乎表明我们远远超出了我们的资源限制。此外，在高级层，我们应该保证我们的DTU级别为秒。但是，再一次，我们不仅没有能够获得数据库连接，而且还有一整天的时间。发生了什么事？

我还可以说，在我们遇到其中一个较长的延迟后，我们的统计数据似乎重置了。上面的图像是在1分钟+延迟之前的几分钟，这是几分钟之后：

Answer 1

我们一直与Azure的技术人员保持联系，他们确认这是他们平台中的一个错误，导致我们的数据库每天多次进行故障转移。他们表示，他们将在本周开始部署修复程序，并在下个月继续进行修复。

坦率地说，我们无法理解任何人如何在Azure上可靠地运行Web服务。我们的网站池每月随机下降几分钟几次，将我们的公共网站关闭。如果我们的云服务返回了太多500个响应，它前面的东西就是切断所有流量并返回502（据我们所知，完全没有记录的行为）。 SQL Azure的性能非常有限，显然还没有准备好迎接黄金时段。