Share via

Windows Azure Storage 性能调优（一）

WAS (Windows Azure Storage) 是微软提供的云存储服务，也是整个Azure服务的基石，几乎所有Azure产品都依赖于WAS。WAS的性能也紧紧影响到其他服务的性能。在这篇文章中，我总结一下使用WAS的经验，与大家分享。

WAS使用HTTP(S) 协议，访问操作通过发送HTTP请求来完成。访问操作的时间可由Request传输时间、Response传输时间和服务端处理时间组成。

 

为了提高性能，开发人员可以尝试减少每个过程的时间。总结起来，有如下一些方法：

 此文章介绍网络相关的优化方法。

选择最近的数据中心

网络延迟对任何网络服务的影响都很大。Azure在全球有17+个数据中心，为了减少网络延迟，开发者应该选择离产品用户最近的数据中心。如下网站可以显示你当前的网络访问全球每个数据中心WAS Blob的速度。

https://azurespeedtest.azurewebsites.net/

 

在选择数据中心时，若没有特别原因，开发者需要尽量避免跨数据中心的网络访问，这样会造成额外的流量费用。比如说用户部署Cloud Service在香港，而Cloud Service需要访问 新加坡的WAS来读取数据，那么这个跨数据中心的访问将被额外收取流量费，而且跨数据中心的网络延迟会比数据中心内部访问要高。

使用CDN减少网络延迟

CDN（Content distributed Network） 是一个常用的HTTP访问优化方法， 其原理是：在某个区域或全球范围内分布很多文件缓存节点，尽可能的离用户更近。当用户需要从站点下载文件时，用户直接访问离他最近的缓存节点，若请求的数据已被缓存，则直接返回客户，起到网络提速功能；若请求的数据未被缓存，则从源站点下载。

Azure CDN有两个版本：Global版的CDN由EdgeCast公司提供，在全球24个地点部署有缓存节点。大陆版的CDN委托给ChinaCache运营，主要针对中国区网络。通过Azure CDN，可以加速WAS Blob， Cloud Service 和 Azure Website的网络访问速度，不过WAS Queue和Table不可以。

 

Edgecast 缓存节点分布

减少数据传输

减少传输的数据量可以减少Request或Response的网络传输时间。减少数据的方式可以有压缩数据和裁剪无关数据。

压缩 Windows Azure Blob

Blob类似于文件存储，若文件是文本类型，则压缩文件可以节省很多带宽。比如网站的js，css文件，常用浏览器都支持Gzip压缩，因此在上传前，不妨用Gzip压缩文件。实例代码如下：

 

            var blobClient = new CloudBlobClient(account.BlobEndpoint, account.Credentials);

            blobClient.RetryPolicy = retry;

            var blobContainer = blobClient.GetContainerReference("bundles");

            var blob = blobContainer.GetBlockBlobReference("jquery-1.6.2.js");

            blob.Properties.ContentType = "text/javascript";

            blob.Properties.CacheControl = "public, max-age=3600";

            blob.Properties.ContentEncoding = "gzip";

            using (var compressed = blob.OpenWrite())

            {

                using (var gzip = new GZipStream(compressed, CompressionMode.Compress))

                {

                    using (var filestream = File.OpenRead(filePath))

                    {

                        filestream.CopyTo(gzip);

                    }

               }

           }

如下的一个测试显示，jquery文件经过压缩后，只有原先的1/4大。

 

使用JSON格式

在早期版本的WAS，Table和Queue只支持ATOM格式的消息（XML），现在的版本支持JSON。相比于XML，JSON体积更小，可以更快的传输，并且更容易操作。如下为同样的数据以ATOM和JSON形式呈现，可以明显发现JSON格式更小。

 

 

使用JSON格式，需要在HTTP request header上添加 header “Accept: application/json”

使用实体映射（Entity Projection）

在查询WAS Table时，默认情况下WAS会返回符合实体的所有属性。而在一些情况下，客户端只需要实体的某些属性。WAS Table提供了查询参数 “$select”，通过使用此参数，可以让WAS Table只返回客户端需要的属性。

  

减少请求事务数量

拿现实的例子作比方：淘宝小店发货，如果店主每接到一单就叫快递来拿，那么快递小哥要反复奔走于快递站和淘宝店之间，在取件上耗费了大量的时间。一个更可行的方式是，店主把要发的货屯起来，在每天下午3点叫快递一并拿走，这样快递小哥一天只用跑一次，节省了大量时间。访问WAS也是如此，用户需要发现访问数据的关联性，尽量把所做的操作并在更少的请求事务上。

WAS Table支持Batch操作，即把一组Table操作放到一个Request中完成。Batch即节省了大量耗费在数据传输上的时间，同时又确保事务原子特性。如下代码测试使用Batch一次插入100条记录，通过比较发现，其性能要比逐条插入高出4到16倍。

 

 

 
需要注意的是，WAS Table Batch操作要求访问的实体存在同一个Partition中，操作上限为100。

事务并行化

当事务之间没有先后依赖关系时，可以通过并行执行来提升速度。用过网络快车、网络蚂蚁的人都懂的，使用多个线程同时下载文件的不同部分，然后拼接起来，可以达到更快的下载速度。

对于WAS Block blob，每个Blob又一组Block组成，用户可以用多线程并发的上传Block，当文件的所有Block上传完毕后，最后发一个请求，将blocks按顺序组装起来。由此方法，可以实现多线程上传，提高传输的吞吐量。图下所示，通过并发上传可以基本达到单Blob的性能上限60MB/s。

 

用户可以直接使用微软提供的一个工具AZCOPY，它默认就使用多线程上传。

https://blogs.msdn.com/b/windowsazurestorage/archive/2012/12/03/azcopy-uploading-downloading-files-for-windows-azure-blobs.aspx

其它网络优化

  • 当网络传输的object小于1400字节时，禁用Network Nagle会提高传输性能。
  • 禁用 Expect 100-Continue，减少网络Roundtrip。
  • .NET 通过ServicePointManager来限制Outbound 连接数，默认为2。若程序大量使用并发连接，需要手动调整此阀值。