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。若程序大量使用并发连接,需要手动调整此阀值。