azure存储压测的问题(农码主观意识太强被坑了)

由于公司想把部份业务迁到windowsazure,主要是应用winodwsazure的存储;在方案中为了体现存储的可靠性所以对winodwsazure存储进行了一系列的测试.但在读取压力测试环节中发现间歇性出现文件读取延时的情况,由于自己在编写测试应用方面比较善长(年长的农码),所以把问题归根于winodwsazure的存储上.经过和MS技术多次交流和帮助下才把问题明确下来,虽然问题不是程序代码产生,但和测试方法构建的测试数据有着关系.下面分享一下个测试过程.

目标

        公司希望把网站存储的一些资源放到windowsazure上,总容量大概在3个T左右.出于方案实施严紧性考虑所以制定了一个压力测试计划,主要从读和写两方面来考察一下存储所支援的压力.写测试主要是分别写入:8k,16k,32k,64k,128k不同大小的文件而读取测试则随便获取写入的文件.

测试

        在写入测试的时间还是非常顺利,存储节点的写入带宽基本可以达到3Gb,压力写入测试效果非常理想.但在压力读取的时候就出现异常,基本每隔2-3分钟就会出现读取延时,其延时时间竟然达到3-6秒.然后又恢复正常...

 while (true)            {                stream.Position = 0;                TimeOutLog log = new TimeOutLog();                watch.Restart();                long index = System.Threading.Interlocked.Increment(ref mIndex);                string url = mImages[(int)(index % mImages.Count)];                CloudBlob blob = container.GetBlobReference(url);                blob.DownloadToStream(stream);                System.Threading.Interlocked.Increment(ref mCount);            }

        由于测试代码非常简单,而测试机的CPU和内存都是比较充足,所以直接把问题指向了存储节点上.把问题汇总到winodwsazure方面的技术人员,经过对方调试排查后说程序构建测试的资源URL太多了可能是导致程序出现问题的主要原因.

        在收到问题后我实在不理解,即使测试Url占用大量的内存也不可能影响程序运行,毕竟测试服务器的CPU根本没有压力.由于没有明确是否程序存在问题,所以我试图找方法来证明是存储的原因(毕竟公司采用的方案不能随便了结).通过修改程序把每个环节的运行时候记录下来.

   TimeOutLog log = new TimeOutLog();                watch.Restart();                long index = System.Threading.Interlocked.Increment(ref mIndex);                string url = mImages[(int)(index % mImages.Count)];                watch.Stop();                log.GetUrlTime = watch.Elapsed.TotalMilliseconds;                log.Url = url;                watch.Restart();                CloudBlob blob = container.GetBlobReference(url);                blob.DownloadToStream(stream);                watch.Stop();                log.GetBlobTime = watch.Elapsed.TotalMilliseconds;                if (log.GetBlobTime > 1000 || log.GetUrlTime > 1000)                    mQueue.Enqueue(log);                System.Threading.Interlocked.Increment(ref mCount);

        添加处理时间后明确发现是blob的downloadToStream存在间歇延时的情况,由于这个winodwsazure的API是由官方提供的.所以下了个定论程序不存在问题,应该是存储方面出现异常,然后邮件winodwsazure技术要求他们帮忙跟进一下.经过沟通对方建议把测试的url裁剪成N小分然后由开启多个程序进行压测,这个工作对我来说是比较方便调整,于是就把url拆分成N小份测试,结果没想到整个测试都非常顺利.

结总

        .net程序占用大量内存后为什么影响downloadToStream导致延时的问题现在还没有清楚(毕竟不影响对存储的考察所以就没有再研究下去了),由于自己在编写.net程序有一定经验,所以开始坚信不是程序方面出的问题...刚开始挺排斥说是数据或程序原因导致的问题.后面拆成N个小文件的动机也是为了更进一步想证明存在问题.结果论证了我的想法是错误的,有时凭某方面的经验主观的判断一个事情的确是件很不好的方式.以下分享一下winodwsazure存储的测试结果

winodwsazure单个结点的存储读写还是非常给力的,基本按MS所说的一个帐号达到3Gb的读写流量.

 补充:说句心理话MS的技术服务真的很倒位,虽然公司还没有正式购买服务,不过已体会到支持的到位(在这里谢谢技术支持的徐总)