Azure 计算实例答案

【问题标题】：Azure compute instancesAzure 计算实例
【发布时间】：2012-01-21 03:07:59
【问题描述】：

在 Azure 上，我可以以 1 小号的价格获得 3 个额外的小实例。我不担心我的网站无法扩展。

还有什么其他原因我不应该选择 3 个额外的小而不是 1 个小？

【问题讨论】：

【解决方案1】：

一个 Extra Small 实例被限制为大约。 NIC 上的带宽为 5Mbps（与 Small、Medium、Large 和 XL 的每个内核大约 100Mbps 相比），并且 RAM 小于 1GB。所以，假设您正在运行一些存储密集型的东西。您可能会在访问 SQL Azure 或 Windows Azure 存储时遇到瓶颈。

使用 RAM：如果您正在运行 MongoDB 等 3rd 方应用程序，您可能会遇到内存问题。

从可扩展性的角度来看，您可以将负载分散到 2 或 3 个 Extra Small 实例上是对的，并且您将获得良好的 SLA。只需确保您的内存和带宽足以满足您的性能目标。

有关每个实例大小的确切规格的更多详细信息，包括 NIC 带宽，请参阅this MSDN article。

【讨论】：

谢谢。我忘了带宽。

【解决方案2】：

查看细则 - 与 x-small 实例相比，小型实例的 I/O 性能应该要好得多。我不确定这是由于技术相关的瓶颈还是业务决策，但事实就是如此。

另外，我猜测操作系统在每个实例中都占用了一点 RAM，因此在 3 个 X-small 实例中它占用了 3 倍，而不是在一个小实例中只占用了一次。这将减少实际可用于您的应用程序需求的资源。

【讨论】：

【解决方案3】：

虽然理论上 3 个超小型实例在理论上可能等于甚至比一个小型实例“在纸上”更好，但请记住，超小型实例没有专用内核，并且它们的原始计算资源与其他租户共享。我已经尝试过这些超小型实例，以试图为小负载网站节省资金，并且必须说，我发现只是中断或性能糟糕的时候是不可接受的。

简而言之：我不会将超小型实例用于任何类型的生产环境

【讨论】：

XS 实例非常适合调度程序、健康监视器等，因为它们消耗的资源很少，通常依赖于不需要高性能或带宽的存储过程或简单的表存储查询。我同意商业网站可能不适合基于 XS 的网络角色。也就是说：有时网站性能会受到应用程序池回收的阻碍（尤其是低容量网站）。