由于公司想把部份業(yè)務(wù)遷到windowsazure,主要是應(yīng)用winodwsazure的存儲;在方案中為了體現(xiàn)存儲的可靠性所以對winodwsazure存儲進(jìn)行了一系列的測試.但在讀取壓力測試環(huán)節(jié)中發(fā)現(xiàn)間歇性出現(xiàn)文件讀取延時的情況,由于自己在編寫測試應(yīng)用方面比較善長(年長的農(nóng)碼),所以把問題歸根于winodwsazure的存儲上.經(jīng)過和MS技術(shù)多次交流和幫助下才把問題明確下來,雖然問題不是程序代碼產(chǎn)生,但和測試方法構(gòu)建的測試數(shù)據(jù)有著關(guān)系.下面分享一下個測試過程.

目標(biāo)

        公司希望把網(wǎng)站存儲的一些資源放到windowsazure上,總?cè)萘看蟾旁?個T左右.出于方案實(shí)施嚴(yán)緊性考慮所以制定了一個壓力測試計(jì)劃,主要從讀和寫兩方面來考察一下存儲所支援的壓力.寫測試主要是分別寫入:8k,16k,32k,64k,128k不同大小的文件而讀取測試則隨便獲取寫入的文件.

測試

        在寫入測試的時間還是非常順利,存儲節(jié)點(diǎn)的寫入帶寬基本可以達(dá)到3Gb,壓力寫入測試效果非常理想.但在壓力讀取的時候就出現(xiàn)異常,基本每隔2-3分鐘就會出現(xiàn)讀取延時,其延時時間竟然達(dá)到3-6秒.然后又恢復(fù)正常...

 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);            }

        由于測試代碼非常簡單,而測試機(jī)的CPU和內(nèi)存都是比較充足,所以直接把問題指向了存儲節(jié)點(diǎn)上.把問題匯總到winodwsazure方面的技術(shù)人員,經(jīng)過對方調(diào)試排查后說程序構(gòu)建測試的資源URL太多了可能是導(dǎo)致程序出現(xiàn)問題的主要原因.

        在收到問題后我實(shí)在不理解,即使測試Url占用大量的內(nèi)存也不可能影響程序運(yùn)行,畢竟測試服務(wù)器的CPU根本沒有壓力.由于沒有明確是否程序存在問題,所以我試圖找方法來證明是存儲的原因(畢竟公司采用的方案不能隨便了結(jié)).通過修改程序把每個環(huán)節(jié)的運(yùn)行時候記錄下來.

   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);

        添加處理時間后明確發(fā)現(xiàn)是blob的downloadToStream存在間歇延時的情況,由于這個winodwsazure的API是由官方提供的.所以下了個定論程序不存在問題,應(yīng)該是存儲方面出現(xiàn)異常,然后郵件winodwsazure技術(shù)要求他們幫忙跟進(jìn)一下.經(jīng)過溝通對方建議把測試的url裁剪成N小分然后由開啟多個程序進(jìn)行壓測,這個工作對我來說是比較方便調(diào)整,于是就把url拆分成N小份測試,結(jié)果沒想到整個測試都非常順利.

結(jié)總

        .net程序占用大量內(nèi)存后為什么影響downloadToStream導(dǎo)致延時的問題現(xiàn)在還沒有清楚(畢竟不影響對存儲的考察所以就沒有再研究下去了),由于自己在編寫.net程序有一定經(jīng)驗(yàn),所以開始堅(jiān)信不是程序方面出的問題...剛開始挺排斥說是數(shù)據(jù)或程序原因?qū)е碌膯栴}.后面拆成N個小文件的動機(jī)也是為了更進(jìn)一步想證明存在問題.結(jié)果論證了我的想法是錯誤的,有時憑某方面的經(jīng)驗(yàn)主觀的判斷一個事情的確是件很不好的方式.以下分享一下winodwsazure存儲的測試結(jié)果

winodwsazure單個結(jié)點(diǎn)的存儲讀寫還是非常給力的,基本按MS所說的一個帳號達(dá)到3Gb的讀寫流量.

 補(bǔ)充:說句心理話MS的技術(shù)服務(wù)真的很倒位,雖然公司還沒有正式購買服務(wù),不過已體會到支持的到位(在這里謝謝技術(shù)支持的徐總)