目标
公司希望把网站存储的一些资源放到windowsazure上,总容量大概在3个T左右.出于方案实施严紧性考虑所以制定了一个压力测试计划,主要从读和写两方面来考察一下存储所支援的压力.写测试主要是分别写入:8k,16k,32k,64k,128k不同大小的文件而读取测试则随便获取写入的文件.测试
在写入测试的时间还是非常顺利,存储节点的写入带宽基本可以达到3Gb,压力写入测试效果非常理想.但在压力读取的时候就出现异常,基本每隔2-3分钟就会出现读取延时,其延时时间竟然达到3-6秒.然后又恢复正常... while(true) { stream.Position=0; TimeOutLoglog=newTimeOutLog(); watch.Restart(); longindex=System.Threading.Interlocked.Increment(refmIndex); stringurl=mImages[(int)(index%mImages.Count)]; CloudBlobblob=container.GetBlobReference(url); blob.DownloadToStream(stream); System.Threading.Interlocked.Increment(refmCount); } 由于测试代码非常简单,而测试机的CPU和内存都是比较充足,所以直接把问题指向了存储节点上.把问题汇总到winodwsazure方面的技术人员,经过对方调试排查后说程序构建测试的资源URL太多了可能是导致程序出现问题的主要原因. 在收到问题后我实在不理解,即使测试Url占用大量的内存也不可能影响程序运行,毕竟测试服务器的CPU根本没有压力.由于没有明确是否程序存在问题,所以我试图找方法来证明是存储的原因(毕竟公司采用的方案不能随便了结).通过修改程序把每个环节的运行时候记录下来. TimeOutLoglog=newTimeOutLog(); watch.Restart(); longindex=System.Threading.Interlocked.Increment(refmIndex); stringurl=mImages[(int)(index%mImages.Count)]; watch.Stop(); log.GetUrlTime=watch.Elapsed.TotalMilliseconds; log.Url=url; watch.Restart(); CloudBlobblob=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(refmCount); 添加处理时间后明确发现是blob的downloadToStream存在间歇延时的情况,由于这个winodwsazure的API是由官方提供的.所以下了个定论程序不存在问题,应该是存储方面出现异常,然后邮件winodwsazure技术要求他们帮忙跟进一下.经过沟通对方建议把测试的url裁剪成N小分然后由开启多个程序进行压测,这个工作对我来说是比较方便调整,于是就把url拆分成N小份测试,结果没想到整个测试都非常顺利.结总
.net程序占用大量内存后为什么影响downloadToStream导致延时的问题现在还没有清楚(毕竟不影响对存储的考察所以就没有再研究下去了),由于自己在编写.net程序有一定经验,所以开始坚信不是程序方面出的问题...刚开始挺排斥说是数据或程序原因导致的问题.后面拆成N个小文件的动机也是为了更进一步想证明存在问题.结果论证了我的想法是错误的,有时凭某方面的经验主观的判断一个事情的确是件很不好的方式.以下分享一下winodwsazure存储的测试结果 winodwsazure单个结点的存储读写还是非常给力的,基本按MS所说的一个帐号达到3Gb的读写流量. 补充:说句心理话MS的技术服务真的很倒位,虽然公司还没有正式购买服务,不过已体会到支持的到位(在这里谢谢技术支持的徐总)上一篇:azure存储压测的问题(农码主观意识太强被坑了)
