由于公司想把部份業務遷到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的技術服務真的很倒位,雖然公司還沒有正式購買服務,不過已體會到支持的到位(在這里謝謝技術支持的徐總)