哪个在性能，2个中等角色实例或4个小角色实例方面更好？
每种配置的优缺点是什么？
答案 0 :(得分：2)
知道你是否获得使用更大实例的优势的唯一真正方法是尝试和测量，而不是在这里问。 This article有一个表格，表明中型实例的所有内容都是小型实例的两倍。但是在现实生活中，您的里程可能会有所不同，以及这会影响您的应用程序，只有您可以测量。
较小的角色具有一个重要优势 - 如果实例单独失败，则性能会降低。假设您知道至少有两个实例的“保证正常运行时间”要求，您必须在两个中型和四个小型实例之间进行选择。如果一个小实例失败，则会失去1/4的性能，但如果一个中型实例失败，则会失去一半的性能。
例如，如果您的角色入口点后代的Run()内有未处理的异常，实例将会失败，有时候出现错误的时候，你的代码无法解决这个问题，最好只重新启动。并不是说你应该故意针对这些失败，但你应该期待它们并采取措施尽量减少对你的应用程序的影响。
所以最重要的是 - 不可能说哪个性能更好，但正常运行时间影响同样重要，他们显然支持更小的实例。
答案 1 :(得分：2)
@sharptooth的好点。还有一件事需要考虑：在中缩放时，实例数最少的是一个，而不是零。所以，假设你有一个工作角色在一个小时内执行一些夜间任务，并且它需要2个中型或4个小型实例才能在该时间范围内完成工作。完成工作后，您可能希望通过缩放到一个实例来节省成本，并让它作为一个实例运行23个小时，直到下一个夜间工作。使用单个Small实例，您将刻录23个核心小时，而使用单个Medium实例，您将刻录46个核心小时。这种想法也适用于您的Web角色，但可能更多 - 因为您可能至少有两个实例以确保您具有正常运行时间SLA（如果您的工作结束，那么对您的工作人员进行SLA可能并不重要用户从不与它交互，只是出于实用目的）。
调整大小时的一般经验法则：选择可以正常完成工作的最小VM大小，然后根据需要扩展/缩小。您的选择主要取决于CPU，RAM和网络带宽需求（在计算和存储之间移动数据时不要忘记您需要网络）。
答案 2 :(得分：1)
首先，除非您至少有2个角色角色实例，否则您将无法获得99％的保证正常运行时间，这样可以让一个人死亡并重新启动而另一个负担重担。否则，您需要支付多少费用以及每种规格的具体情况。它没有让我有任何麻烦，有多个角色角色实例，Azure隐藏了困难的东西。
答案 3 :(得分：0)
另外一点可能值得一提，如果你使用四个小角色，你可以在一个数据中心运行两个，在另一个数据中心运行两个，并使用流量管理器来路由至少更近的人。这可能会带来一些性能提升。
两种媒介将为您提供更多选项，以便在计算级别的缓存中存储内容，从而更多地在缓存中而不是从SQL Azure中删除它会更快。
理想情况下，您必须关注@sharptooth并进行测量和测试。这一切都是非常主观的，我第二个大卫也希望从尽可能小的开始向外扩展。我们以这种方式运行，你真的想考虑围绕一个更加分散的方面设计你的应用程序，因为这比传统意义上更适合天蓝色模型只需要一个更大的盒子来运行所有东西，在某些时候你会遇到极限思维在更大的盒子进程中，即像SQL Azure连接限制一样。
使用像Jmeter这样的技术是你的朋友，应该给你一些工具来测试你的应用程序。