Windows Azure 宣传三种类型的 IO 性能级别：
因此，如果我有一个 IO 绑定应用程序（而不是 CPU 或内存绑定）并且需要至少 6 个 CPU 来处理我的工作负载 - 我会通过 12-15 个 Extra Smalls、6 个 Smalls 或 3 个获得更好的 IO 性能吗？媒介？
我确信这会因应用程序而异 - 有没有简单的方法来测试它？是否有任何数字可以更好地说明您在迁移到大型实例角色时获得了多少 IO 性能提升？
似乎较小角色的 IO 性能可能与较大角色相当，如果整体负载变得太大，它们只是首先受到限制的角色。听起来对吗？
【问题讨论】：
标签： azure io azure-storage
Windows Azure 计算大小提供大约。每个核心 100Mbps。超小型实例要低得多，为 5Mbps。有关详细信息，请参阅this blog post。如果您受 IO 限制，则 6-Small 设置将提供比 12 Extra-Small 更大的带宽。
当您谈到处理工作负载时，您是在排队工作吗？如果是这样，多个工作角色，每个都是小型实例，然后每个都可以使用 100Mbps 管道。您必须进行一些基准测试以确定 3 Mediums 是否为您提供了足够的性能提升来证明更大的 VM 大小是合理的，知道当工作负载下降时，您每小时的“空闲”成本足迹现在是 2 个内核（中等，0.24 美元） ) 与 1（小，0.12 美元）。
【讨论】：
据我了解，每个内核允许的 IO 量是恒定的，并且应该是专用的。但我无法得到正式确认。对于在共享模式下运行且不像其他 Windows Azure vm 实例那样专用的 x-small 实例，这可能会有所不同。
【讨论】：
我想您所怀疑的实际上是正确的，即使是 IO 绑定也因应用程序而异。我认为您可以通过使用 Timers 并将输出写入存储中的文件来实现计时目标，然后您可以检索该文件。做一些数学计算，您可以通过尽可能多地通过一个小型实例然后中型实例来处理 X 个工作单元/小时。如果您的工作单元大小大幅波动，您可能还需要进行一些平均。如果可能的话，我总是更喜欢较小的实例，并且只是在您需要更多火力时启动更多副本。
【讨论】：