Azure IO性能

Azure虚拟机的大小是基于它们的内存和CPU核心的，但是所有的大小显然都缺乏存储性能，无论虚拟机上有多less核心和内存，它总是成为主要的罪魁祸首。

两种解决scheme

• 对于正常使用，只需将尽可能多的数据磁盘连接到虚拟机，并将其configuration在来宾系统的RAID 0中; I / O被限制在磁盘级别，因此更多的磁盘=更多的I / O。 使用这些磁盘进行实际工作，不要在系统磁盘上放置操作系统以外的任何东西（无论如何，这是最佳做法）。 这种策略没有额外的成本，因为Azure存储是基于实际使用的空间计费的：虚拟磁盘的数量和它们的表观大小完全不重要。 （*）
• 如果您确实需要磁盘性能，请使用高级存储 。

（*）如果您担心使用RAID 0，不要这样做。 这些是虚拟磁盘，它们的完整性已经由底层存储层保证。 RAID 0仅用于将它们分组在单个逻辑卷中，并具有更好的性能。

Azure是一项共享服务。 您应该期望基于您正在运行的虚拟机pipe理程序（您完全无法控制）的负载以及无数其他因素（您无法控制）的无数性能随机性能变化。

如果性能（和一致性）在您自己的硬件上承载您自己的环境至关重要。

您不应该使用您的c驱动器应用程序：

http://blogs.msdn.com/b/igorpag/archive/2014/10/23/azure-storage-secrets-and-linux-io-optimizations.aspx

C驱动器针对启动时间进行了优化，而不是针对高IO。

由于每个磁盘都是IOPS节制的（通常为500 /磁盘），因此您可以使用其中的很多（A3上最多8个），也可以使用具有SSD（D3：12000IOPS）的d系列机器。 请注意，您必须使用不保证持久数据具有SSD速度的D盘：

http://azure.microsoft.com/blog/2014/10/06/d-series-performance-expectations

或者，您可以支付$$$并使用高级存储blob（5000 IOPS〜100 $ / Month）来获得持久性存储。

大约6个月前，我们将整个生产环境迁移到了Azure。 我们有一个每天运行多个构build的构build服务器，并基于从构build到构build的各个构build任务的持续时间，我可以告诉你“性能”是相当一致的。 我还可以确认你的发现，与本地开发PC相比，不使用多核的进程（例如运行unit testing）在Azure虚拟机上运行速度慢大约6倍。

简而言之，当你在一个核心上运行进程时，你的本地机器将总是胜过Azure虚拟机。 我认为Azure更适合处理涉及多个内核的任务（例如数据库或Web服务器），因为您可以根据需要轻松扩展/缩减内核。