我正在尝试将数千个小Blob写入Azure存储时找出性能最佳的方法 . 应用场景如下：
安装在Windows Azure VM上的不断运行的Windows服务正在创建或覆盖
-
千个文件
-
写入VM可用的临时存储，该服务每秒可以达到9,000多个文件创建
-
文件大小介于1 KB和60 KB之间
在运行相同sw的其他VM上 -
，正在使用相同的速率和条件创建其他文件
-
鉴于需要构建并保持更新中央存储库，每个VM上运行的另一个服务将新创建的文件从临时存储复制到Azure Blob
然后 -
其他服务器应该在更新版本中读取Azure Blob
请注意，对于许多我没有列出的简短约束，目前无法修改主服务以直接创建Blob而不是临时文件系统上的文件 . ......而且从我目前看到的情况来看，这意味着创作速度较慢，而且根据原始要求是不可接受的 .
这个复制操作，我在调整了名为"Windows Azure ImportExportBlob"的示例代码之后能够达到此结果：此处找到了http://code.msdn.microsoft.com/windowsazure/Windows-Azure-ImportExportB-9d30ddd5，并在此答案中找到了异步建议：Using Parallel.Foreach in a small azure instance
我在具有8个内核的超大型VM上获得了每秒200个blob创建的最大值，并相应地设置了“maxConcurrentThingsToProcess”信号量 . 测试期间的网络利用率是任务管理器中显示的可用10Gb的最大1％ . 这意味着该VM大小应该可用的800 Mb大约100 Mb .
我看到在经过的时间内复制的总大小给了我大约10 MB /秒 .
您可以生成的Azure存储流量是否有一些限制，或者在编写这么多小文件时我应该使用不同的方法吗？
1 回答
@breischl感谢您的可扩展性目标 . 阅读完这篇文章之后，我开始寻找可能由微软准备的更多目标人物，并发现了4个帖子（我的“声望”太多了，这里发布了，其他3个是同一系列的第2,3和4部分）：
http://blogs.microsoft.co.il/blogs/applisec/archive/2012/01/04/windows-azure-benchmarks-part-1-blobs-read-throughput.aspx
第一篇文章包含一个重要提示： "You may have to increase the ServicePointManager.DefaultConnectionLimit for multiple threads to establish more than 2 concurrent connections with the storage."
我将其设置为300，重新运行测试并看到MB / s的重要增加 . 正如我之前写的那样，当"too many"线程正在编写blob时，我正在考虑在底层blob服务中达到限制 . 这证实了我的担忧 . 因此，我删除了对代码所做的所有更改以使用信号量，并使用parallel.for再次替换它以启动尽可能多的blob上载操作 . The result has been awesome: 61 MB/s writing blobs and 65 MB/s reading.
可扩展性目标是60 MB / s，我终于对结果感到满意 .
再次感谢大家的回答 .