我的客户端通过高延迟连接访问 Azure 存储，速度缓慢的主要原因似乎是每次调用之间的延迟。
每个用户以下情况会发生数百次
获取平面目录列表
获取列出的 blob 的页面
请求页面中的数据
该应用程序利用了 PageBlob 的“稀疏”特性以及 512 字节的小分配单元，但这会产生创建过多事务的副作用。
我可以对具有不同名称的对象的多个“获取页面范围”或“获取页面 Blob”请求进行批处理吗，就像在同一个 HTTP 请求中一样：
GET /containerName/Hourly/2012/01/01/02
GET /containerName/Hourly/2012/01/01/03
GET /containerName/Hourly/2012/01/01/04
GET /containerName/Hourly/2012/01/01/05
或者相同的问题适用于 PUT 的类似操作
I have clients accessing Azure storage on a high latency connection, and it appears that the main reason for the slowness is the latency between each call.
The following happens several hundred times per user
Get flat directory listing
Get the pages of the blobs that are listed
Request the data in the pages
The application is taking advantage of the "sparse" nature of the PageBlob, and the small allocation units of 512 bytes, but that has a side effect of creating too many transactions.
Can I batch together several "Get Page Range" or "Get Page Blob" requests for objects with different names, like this in the same HTTP request:
GET /containerName/Hourly/2012/01/01/02
GET /containerName/Hourly/2012/01/01/03
GET /containerName/Hourly/2012/01/01/04
GET /containerName/Hourly/2012/01/01/05
or the same question goes for similar operations with PUT
发布评论
评论（1）
您可以在您和 Azure 存储之间放置自己的服务，然后可以在单个操作中组合多个内容。然而，这可能不是一个好主意。
最好将调用保留为单独的操作，但异步且并行地执行它们。
查看此链接的示例：http://blogs.msdn.com/b/kwill/archive/2011/05/30/asynchronous-parallel-block-blob-transfers-with-progress-change-notification.aspx
You could place your own service between you and azure storage, then you could combine several things in a single operation. However, this may not be a good idea.
It may be better to leave the calls as separate operations, but do them asynchronously and in parallel.
Have a look at this link for an example: http://blogs.msdn.com/b/kwill/archive/2011/05/30/asynchronous-parallel-block-blob-transfers-with-progress-change-notification.aspx