Azure cspkg上传速度
...非常慢。我们尝试通过 VS2010 工具部署一个 280 MB 的 cspkg 文件，上传大约需要 35 分钟，部署还需要 10 分钟。
有什么方法可以加快这个上传过程吗？我们正在考虑将不变数据放入 blob 中并从那里提取数据，但我们首先想知道发生了什么。
进行编辑以反映我们正在使用 vs2010 azure 集成工具
... is very slow. We're trying to deploy a 280 MB cspkg file through the VS2010 tools, and it takes roughly 35 minutes to upload, and another 10 minutes to deploy.
Are there any ways to speed up this upload process? We're comptemplating putting invariant data into a blob and pulling it from there, but we'd like to know what's happening in the first place.
edited to reflect we're using vs2010 azure integration tools
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
两种部署方法（API 和门户）都允许从已上传到 Azure 存储的文件进行部署。 VSTS 工具只是在幕后利用此功能。 （在 2010 年，您必须为此提供存储凭据）。
您应该考虑直接将 .cspkg 上传到 Blob 中（而不是通过 VSTS，然后编写一个简单的上传客户端，将上传分成块，这些块可以同时上传。然后您可以调整它（块大小和数量）一次阻止上传），以便更好地利用您的传出带宽，然后您只需使用 API 在 Azure 中“组装”它们，
我认为 这确实可以加快上传速度。发生”，您只是获得到 Azure 存储的同步 WebClient I/O，以及随之而来的所有限制。
Both deployment methods (API and Portal) allow you to deploy from a file that is already uploaded to Azure Storage. The VSTS tools are just utilizing this feature behind the scenes. (In 2010 you have to provide storage credentials for this reason).
You should look into uploading the .cspkg into a Blob directly (vs through VSTS, and then write up a simple upload client that will break the upload into blocks, which can be uploaded simultaneously. You can then tweak this (block size and # of blocks uploading at a time) to better utilize your outgoing bandwidth. Then you just use the api to "assemble" them in Azure once they are all there. This should really speed up the upload.
I think to answer your question as to "whats happening", you are just getting synchronous WebClient I/O to Azure Storage, and all the limitations that come with it.
我们最近遇到了一个非常相似的问题，因为我们必须打包大约 40MB 的第 3 方库才能建立从 Windows Azure 到 Oracle 的 SQL 连接。
通过 Lokad.CQRS，我们完全按照您的建议做了，也就是说，将所有大静态库并保持 Azure 包尽可能精简。它工作得非常好。
We have been hitting a very similar problem recently, as we had to package about 40MB of 3rd party libraries to establish a SQL connection toward Oracle from Windows Azure.
Through Lokad.CQRS, we did exactly what you suggest, aka, putting all big static libraries and keeping the Azure package as lean as possible. It works very nicely.