就性能而言，2 个中等角色实例还是 4 个小角色实例哪个更好？
每种配置的优缺点是什么？
问问题
695 次
4 回答
2
了解您是否从使用更大的实例中获益的唯一真正方法是尝试和衡量，而不是在这里询问。这篇文章有一张表，说明中型实例的所有内容都是小型实例的两倍。然而，在现实生活中，您的里程可能会有所不同，而这会如何影响您的应用程序，只有您可以衡量。
较小的角色有一个重要的优势 - 如果实例单独失败，您会获得较小的性能下降。假设您知道至少有两个实例的“保证正常运行时间”要求，您必须在两个中型实例和四个小型实例之间进行选择。如果一个小型实例发生故障，您将损失 1/4 的性能，但如果一个中型实例发生故障，您将损失一半的性能。
Run()例如，如果您的角色入口点后代中有未处理的异常，并且有时会出现大问题并且您的代码无法处理此问题，那么实例将失败，最好重新启动。并不是说您应该故意针对此类故障，而是您应该预料到它们并采取措施尽量减少对您的应用程序的影响。
所以底线是——不可能说哪个性能更好，但正常运行时间的影响同样重要，它们显然有利于更小的实例。
于 2013-05-30T09:09:02.133 回答
2
@sharptooth 的优点。还要考虑的一件事：缩小时，最少的实例数是1，而不是0. 因此，假设您有一个工作角色，每晚执行一个小时的任务，并且需要 2 个中型或 4 个小型实例才能在该时间范围内完成工作。工作完成后，您可能希望通过扩展到一个实例并让它作为一个实例运行 23 小时直到下一个夜间作业来节省成本。使用单个小型实例，您将消耗 23 个核心小时，使用单个中型实例，您将消耗 46 个核心小时。这种想法也适用于您的 Web 角色，但可能更是如此，因为您可能至少有两个实例来确保您有正常运行时间 SLA（如果您的工作人员有 SLA 可能并不那么重要，例如，您的最终用户从不与它交互，它只是为了实用目的）。
我在调整大小时的一般经验法则：选择可以正确完成工作的最小 VM 大小，然后根据需要横向扩展/缩减。您的选择主要取决于 CPU、RAM 和网络带宽需求（不要忘记在计算和存储之间移动数据时需要网络）。
于 2013-05-30T10:56:28.130 回答
1
首先，除非您至少有 2 个，否则您将无法保证 99% 的正常运行时间角色角色实例，这允许一个死亡并重新启动，而另一个承担负担。否则，这取决于您要支付多少费用以及您获得的每个规格。它并没有给我带来不止一个的麻烦角色角色实例，Azure 隐藏了困难的东西。
于 2013-05-30T08:28:38.317 回答
0
另一点可能值得一提，如果您使用四个小角色，您将能够在一个数据中心运行两个，在另一个数据中心运行两个，并使用流量管理器来路由人员，至少哪个更近。这可能会给您带来一些性能提升。
两种媒介将为您提供更多选择，以在计算级别将内容存储在缓存中，因此在缓存中存储更多，而不是脱离 SQL Azure，它会更快。
理想情况下，您必须遵循@sharptooth 并进行测量和测试。这都是非常主观的，我也支持大卫，你想从尽可能小的开始并向外扩展。我们以这种方式运行，您真的想考虑围绕更多分片方面设计您的应用程序，因为这比传统意义上的工作更适合 azure 模型，即只是获得一个更大的盒子来运行所有内容，在某些时候您会遇到极限思考在更大的盒子过程中，即像 SQL Azure 连接限制。
使用 Jmeter 之类的技术是您的朋友，应该为您提供一些工具来测试您的应用程序。
于 2013-05-30T15:18:32.237 回答