6

在将数千个小 Blob 写入 Azure 存储时，我试图找出性能最佳的方法。应用场景如下：

  • 安装在 Windows Azure VM 上的持续运行的 Windows 服务正在创建或覆盖数千个文件
  • 写入虚拟机可用的临时存储，该服务每秒可以创建超过 9,000 个文件
  • 文件大小介于 1 KB 和 60 KB 之间
  • 在运行相同 sw 的其他 VM 上，正在以相同的速率和标准创建其他文件
  • 鉴于需要构建并保持更新中央存储库，每个 VM 上运行的另一个服务将新创建的文件从临时存储复制到 Azure Blob
  • 然后其他服务器应在其更新版本中读取 Azure Blob

请注意，对于我没有列出的许多限制，目前无法修改主要服务以直接创建 Blob 而不是临时文件系统上的文件。...从我目前看到的情况来看，这意味着创建速度较慢，按照原始要求是不可接受的。

我正在对 10,000 个文件进行紧密循环测试的此复制操作似乎被限制为每秒创建 200 个 blob。在调整此处找到的名为“Windows Azure ImportExportBlob”的示例代码后，我已经能够达到此结果：http ://code.msdn.microsoft.com/windowsazure/Windows-Azure-ImportExportB-9d30ddd5 以及在中找到的异步建议这个答案：在一个小的天蓝色实例中使用 Parallel.Foreach

我在具有 8 个内核的超大型 VM 上获得了每秒 200 个 blob 创建的明显最大值，并相应地设置了“maxConcurrentThingsToProcess”信号量。测试期间的网络利用率最大为任务管理器中显示的可用 10Gb 的 1%。这意味着大约 800 Mb 中的 100 Mb 应该在该 VM 大小上可用。

我看到在经过的时间内复制的总大小给了我大约 10 MB/秒。

您可以生成的 Azure 存储流量是否存在一些限制，或者在编写如此多的小文件时我应该使用不同的方法吗？

4

1 回答 1

2

@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

第一篇文章包含一个重要提示：“您可能必须增加多个线程的ServicePointManager.DefaultConnectionLimit才能与存储建立超过 2 个并发连接。”

我已将其设置为 300 ，重新运行测试并看到 MB/s 显着增加。正如我之前所写的，当“太多”线程正在写入 blob 时，我正在考虑达到底层 blob 服务的限制。这印证了我的担忧。因此，我删除了对代码所做的所有更改以使用信号量并再次将其替换为 parallel.for 以启动尽可能多的 blob 上传操作。结果非常棒：61 MB/s 写入 blob 和 65 MB/s 读取。

可扩展性目标是 60 MB/s，我终于对结果感到满意。
再次感谢大家的回答。

于 2012-11-05T13:25:27.493 回答