Web数据库的性能似乎比新的Azure SQL DB服务层更快？

Question

我正在使用MVC3，EF5，LINQ，.NET4.5，SQL数据库。

微软刚刚提出了SQL数据库的新服务级别，即Basic，Standard和Premium。

最初我使用的是“Web”SQL数据库，因为我的数据库很小，例如大约30mb。然而，在我的测试网站实例中，我一直在使用基本网站和“基本”SQL数据库设置来节省资金。

我有一个“较慢”的运行查询，当我的实时数据库恢复为测试实例上的“基本”新样式数据库时，突然花费了9秒。它现场工具约2.5秒。当我将这个测试数据库实例扩展到“标准”SO，20个DTU时，耗时3.9秒。当我将这个数据库缩放到“退休”的“Web”格式时，它花了1.9秒让我感到惊讶。就好像需要将数据库扩展到S1以获得与旧的“Web”风格的数据库相媲美的性能，但我怀疑这会比旧的“Web”格式数据库花费更多。

我很欣赏上面的任何评论，特别是如果其他人发现新的DB风格可能会更慢。

在一天结束时，新DB风格中的设置是旧的“Web”风格等同于？

谢谢。

EDIT（这真是真让人担心）

我发现这个非常有用的文件，我最担心的事情证实 看到Web/Business comparison with new SQL Database service tiers。这些都非常非常令人担忧，因为网络数据库的性能似乎只能通过“Premium P1”版本来匹配，而我们无法承受这一点。所以暂时我们会继续使用“网络版”。

编辑，似乎已经触及痛处....大约有这么多的人担心....

见：Forum chat with worried users

反馈.NET用户组

我在最近的一次用户组会议上，我也与许多使用.NET对等方的Azure进行了交流，他们也非常担心他们相信开发人员会离开Azure。我认为微软在这里犯的一个主要错误就是将基本的性能设置在Web以下（大部分时间），甚至是在网络之下的S1和S2。只有当你进入P1和P2时，你才会遇到票面价值，并且由于对费用的影响，我们不敢在测试中使用它。根据我们的经验，Web已经在90％的时间里以这样高的水平完成了。我猜这10％是在那里，因为你说的是​​这样，但我们的客户没有对此抱怨。然而，为了保持我们当前的业绩水平，我们需要升级到S2或P1，这对我们的月费有非常大的影响。吉姆兰德的反馈是赞赏，并支持我们的担忧。

Answer 1

我是上述博文的作者。该帖子的更新版本可用： http://cbailiss.wordpress.com/2014/09/16/performance-in-new-azure-sql-database-performance-tiers/

我进行的测试主要围绕新服务层的物理I/O功能。从这些测试中，我相信P1提供的平均I/O大致与Web/Business相同。

因此，具体回答你的问题：

在一天结束的时候，有什么设置在 新DB的风格是旧的“网络”的风格等同于？

如果你对网络/业务的物理I/O限制运行（粗略地讲200MB +读，50MB +每分钟写的），那么我会说需要一个最低P1来提供同等的I/O性能的新服务层。

如果平均而言，您的I/O通常比上述数据少得多，那么数据库可能会在其中一个标准层上执行OK。

我的测试没有量化/比较Web/Business和新层次之间的CPU或内存差异，但它们也在新世界中按照服务层次进行扩展。 master数据库中的sys.resource_stats DMV可以为您的工作负载提供一些洞察。有关更多详细信息，请参阅上面的较新博文。

为了完整，值得一提的是，新的服务层也提供了一些其他的优势有可能支持更多的并发连接，新的可用性功能，新的备份功能等

希望帮助...

编辑：2015年1月：作为Azure SQL数据库v12版本的一部分，新的标准S3性能级别当前处于预览状态。这看起来似乎可以提供比迄今为止更接近于商业版的价格。另外，v12中的每个服务层和性能级别都将获得更高的性能。请参见我的博客文章详细内容： https://cbailiss.wordpress.com/2014/12/17/azure-sql-database-v12-performance-tests-show-significant-performance-increase/

克里斯

Answer 2

System.Data.SqlClient.SqlException：超时过期。操作完成之前超时的时间或服务器没有响应。上周四打这个。将数据从旧系统转换为SQL Azure。选择新标准（S2）而不是5个演出网站（退休）数据库。 SQL：

UPDATE Invoice 
SET SalesOrderID = O.SalesOrderID 
FROM Invoice 
INNER JOIN SalesOrder AS O ON Invoice.InvoiceID = O.InvoiceID 

196043行。跑了，花了4分钟。导出数据库并将其重新加载到Web版本中。查询耗时19秒。总数据库大小约为750兆字节。底线，这不仅仅是“一点点担心”。除非微软在新的基本版/标准版/高级版上获得了现在版本中的性能，否则他们几乎可以亲吻Azure再见。完全不合理的是，除非数据在缓存中，否则只能在196043行上运行查询。用关系数据库进行分析非常重要。

本周我将就此事向我的客户提供建议。毫无疑问，他将联系微软的高层管理人员。

Answer 3

Jim，我很乐意提供帮助。我们知道改变商业模式是一件很难的事情。在网络/商业案例中，您支付数据库的大小，并获得当时我们拥有的任何业绩。有时候这很棒，有些时候这很好，有时候性能很差。客户向我们反馈说，这种难以预测的性能很难处理。

使用此反馈作为关键输入，Basic/Standard/Premium的商业模式为$/perf。在转移到B/S/P之前，了解您的消费资源是不错的第一步。我们有几条新指南可以帮助您做到这一点

http://azure.microsoft.com/en-us/documentation/articles/sql-database-upgrade-new-service-tiers/ 您的里程可能会有所不同。由于这种商业模式的变化，许多客户看到减少。其他人认为没有影响，如果他们的数据库非常小并且消耗大量资源，其中一些会看到增加。我和团队会很乐意帮助客户进入新的商业模式。要进行精彩的对话，需要一些不能在公共论坛中共享的特定客户。 guyhay @ microsoft是我的电子邮件，如果你想有这个谈话。