9

Azure Web 角色和Sql Azure 延迟

嗨，只是想知道Web 工作者角色和SQL Azure之间存在延迟和超时 ，有时会发生超时（这些不是随机的） 100 次 ping 的 40% 没有 0 毫秒超时

如果 Web 工作者角色和 SQL Azure 在同一个数据中心中 为什么在使用内部网络进行通信时会出现超时

请参考随附的屏幕截图：

在此处输入图像描述

在这个网络工作者角色上运行的应用程序有一个神秘的性能起伏......如果可能是由于各种原因，但我需要知道的是这些关于延迟和超时的统计数据是否会影响 Web 应用程序的性能？

谢谢，

4

2 回答 2

17

我在另一个线程上发布了这个，但它很旧并且已经关闭。我认为它突出了你的一些问题。

我一直在尝试将我们的业务应用程序迁移到云端。考虑到我们的现场服务器已有 8 年以上的历史，Azure 服务应该会有显着的改进。然而，当我们测试我们的应用程序并对云和现场进行基准测试时，我们注意到云中的延迟比现场（8 年以上的旧服务器）总体上多出近 3 倍，而当您使用现代设备比较它们时，延迟多出 20 倍。我们的应用程序是一个 asp.net 应用程序，数据库大小约为 11 GB。

SQL Azure 和性能

  1. 切勿在云中使用池连接。如果这样做，您的查询将左右和居中放置。而是打开一个连接并保持打开状态，直到完成。
  2. 使用缓存。如果您希望完成这项工作，您别无选择。我在云中有一个成功的站点，但我不得不使用缓存来获得任何合理的性能。
  3. 意识到这不是你的错！Azure 团队比你更需要解决他们的问题。我们有一个精简的应用程序，我们已经升级、调整和优化了 10 年，如果我们不能让它工作，那么你也不会。

我喜欢 Azure 作为一个概念。我喜欢这些选项。我喜欢可扩展性，但我不喜欢性能。我希望微软对此给予更多关注并做出一些改变，因为在这个问题得到解决之前，任何人都不应该将他们的业务转移到那里。

测试

测试是通过运行一系列访问完全相同的数据的查询来完成的，并通过一个自定义函数在代码中完成，该函数测量从创建对象到处理对象的时间（强制写入数据库）的响应时间。该对象包装了正在测试的代码。

没有为测试启用缓存，但是我确实允许代码和数据库之前执行一次并获得最佳结果，以便数据库服务器有机会优化查询，因此 Web 服务器可以正确加载程序集。

测试 1 - 同一台好机器上的 Web 和 DB

  • 四核 2.5GHz，8GB Ram @ 800Mhz，1300 FSB 和 SQL 2005
  • 产生290 毫秒的响应时间。

测试 2 - 同一台机器上的 Web 和 DB

  • 2 Proc 上的 SQL 和 Web（双核 3.0GHz），16GB Ram @ 200Mhz，200 FSB 和 SQL 2005 真正旧的 IBM 服务器。
  • Web 和 SQL 都是本地的
  • 产生656 毫秒的响应时间。

测试 3 - Web 与 DB 分离

  • SQL on 2 Proc（双核 3.0GHz），16GB Ram @ 200Mhz，200 FSB 和 SQL 2005
  • Web on 1 Proc 双核 3.0GHz，8GB Ram @ 200Mhz，200 FSB
  • 真正古老的 IBM 服务器。
  • 一台机器上的 Web 和另一台机器上的 SQL。
  • 产生796 毫秒的响应时间。

测试 4 - Azure

  • Azure 上的中型 VM
  • SQL Azure 数据库
  • 产生3,174 毫秒的响应时间。

结论

  • 从一台服务器场景转移到两台服务器场景时，我的延迟差异为140 ms。
  • 从该场景迁移到 Azure 需要2,518 毫秒。这比我使用 8 年的机器性能差 17.98 倍。

在他们解决此问题并花时间让他们知道这对您来说也是一个问题之前，请不要这样做。

于 2012-10-27T12:42:29.233 回答
8

首先，您需要知道 Windows Azure SQL 数据库是作为服务提供的多租户、高密度 RDBMS。这意味着，可能有数百个客户使用单个服务器。

我还建议您了解服务的 SLA，尤其是Windows Azure SQL 数据库。没有人声称会有 0 毫秒的延迟。在 Windows Azure SQL 数据库中还有“瞬态条件”之类的东西。

推荐阅读Windows Azure SQL 数据库性能和弹性指南。

至于web应用性能，看了Performance and elastic guide之后，我不认为偶尔出现的200ms是核心瓶颈。

第一条评论后更新

在共享的环境中，您总是会起起落落。您还应该期望查询执行时间上下变化。在那种环境中，这是不可避免的，你必须为之设计和生活。在 Windows Azure SQL 数据库的情况下，这里没有魔杖，也没有为您（我们）提供的专用服务器。如果您认为您的应用程序需要更可靠的 SQL Server 服务，您可以尝试使用 Windows Azure 虚拟机并自己创建一个 SQL Server 集群。我猜想（这只是一个猜测）你的云服务和你的虚拟机之间的通信，假设一切都在同一个可用性集中，将更加可预测。

在第二条和第三条评论后更新：

好吧，是的，您可能有许可问题（我是许可专家）。你开的票是涨跌的吗？如果是这样，您可以尝试升级它（不知道如何，但您有您的工单 ID，您还必须有指定的工程师和有关工单的电子邮件 - 回复所有该电子邮件） . 此外，当您创建工单时，必须有一份小型调查问卷来反映您的问题对业务的影响。然后必须为工单分配通常的响应时间。如果在这段时间内没有给您提供支持，您绝对可以将其升级。

更新

我的有趣观察是，在您的所有屏幕截图中，只有第一个数据包被延迟，然后每个连续数据包都有 0 延迟。在您提供的所有样品中。如果这是您的情况 10 次中的 10 次，那么您绝对没有任何延迟问题。我建议您在常规 ping 中使用“-t”选项发送超过 4 个数据包并观察。我建议在大约 100 个数据包时断开，然后观察结果。我不会考虑 4 个数据包样本，其中只有第一个数据包样本对任何性能审查都有延迟。

于 2012-07-20T07:46:29.973 回答