定量的CDN加速效果分析

指路牌

• CDN
• 網站靜態資源加速
• 定量展現CDN加速效果
• CDN配置好了可是沒有加速效果？

適用場景

• 「第一次接觸」用戶體驗提高
• 網站具備大量圖片、css、js等靜態資源
• ECS購買了固定帶寬，帶寬成爲性能瓶頸

環境

• 一個已完成「備案」的域名

域名購買後須要實名認證+備案，大概須要花費「14～20天」。

• 開通阿里雲CDN服務

參考博客

Web項目彙集地 --- 一文讀懂 CDN 阿里雲 --- CDN文檔

背景

我曾接觸過兩個項目，一個是基於web的AR項目，一個是使用了大圖的展現性項目。兩個項目都有一個共同特色：加載速度很慢。慢到什麼地步呢？頁面徹底加載完的時間量級均在兩位數（10s左右），極端狀況下甚至會達到20s甚至更久。

如此打開速度對於一款應用的體驗來來講是災難級的，由於不會有一個用戶有耐心等待如此長的時間，web前端針對加載速度慢在技術上具備不少解決方案：如使用一張像素很低體積很小的圖片先顯示以「安慰」用戶，或使用分批加載等。

但以上兩種方案都沒法解決我碰到場景的問題，由於AR項目的js文件與AR文件都一樣龐大，以上方案都不能徹底挽救兩位數量級加載時間的災難級體驗。

幸運的是兩個項目都是展位性質的，只須要利用瀏覽器自身的緩存機制，提早打開幾回頁面就能將加載時間將時間輕易降到50ms附近，讓觀衆戶徹底感受不到加載的耗時。

可是如此雨來，展現的互動性將變得很受限，由於用戶沒法使用本身的設備親自打開體驗應用，只能使用講解員手中提早緩存好數據的設備。

我調研CDN的初衷，也是爲了嘗試解決以上問題：可以讓徹底沒有緩存用戶的設備在「第一次接觸」應用時可以較快打開應用，提升互動性。

原理&思路

要解決現有的問題，那麼須要先分析一下性能瓶頸到底出在了什麼地方。網頁加載速度慢的根本緣由固然是文件過大，但監控服務器資源佔用等參數後我將參數鎖定在了兩個：地理位置、帶寬。

接下來咱們就來看看CDN到底能不能實現加速，以及可以加速到什麼地步？

步驟

爲了肯定上面兩個問題，我選取了項目中的部分文件做爲用例，作了一系列測試，獲得三組對比數據以下：

1、境內外ECS對比

• 「行」爲該文件加載耗時，單位爲ms、s
• 時間讀取自Chrome控制檯
• 禁用了瀏覽器cache，爲了不偏差每次測試前均再一次手動刪除緩存圖片與記錄。
• 每一個文件在一個ECS測試3次，所以每一個文件一共2組，6個數據。
• AWS的ECS在帶寬上遠比Ali的ECS高，Ali這的ECS的帶寬爲固定帶寬5Mbps（也即0.625MB/s）。

現象

• 位於奧蘭多的服務器和位於張家口的表象不相上下，
• 文件大小達到4MB左右均會開始向10s逼近，

結論： 因爲空間位置緣由沒法獲取文件在奧蘭多處的加載耗時，不嚴謹的得出結論：AWS在帶寬上彌補了物理距離的差距，兩者速度差別不大。

2、在AliCloud的ECS，使用CDN加速與不使用CDN加速對比

C、D、E三列爲先前測試數據 F、G、H、I列爲使用CDN加速後測試數據 G爲同局域網下同事電腦 H、I爲使用手機熱點4G網絡下在另外一臺設備Mac上的時間表現

現象

• F列爲本人PC，具備很是明顯的加速效果，
• G、H、I三列均沒有任何變快表現，甚至還更慢了......

結論：

• Ali的CDN難道是針對單個IP進行加速，來欺騙消費者的嗎？

這個結論固然是錯的，可是數據上又呈現出了以上特色，又是什麼緣由致使的呢？繼續往下看

3、在AliCloud的ECS，使用CDN加速，並進行「數據預熱」後數據對比

C、D、E爲第一組測試數據，無CDN狀況下性能表現 F爲第二組測試數據，進行CDN加速但無數據預熱時在一臺新設備上的性能表現 H、I、J爲使用CDN加速後，分別在同事G與另外兩個徹底沒有開過網站的設備上打開網站的性能表現。

現象

• 在沒有數據預熱前，CDN加速基本沒有任何提速效果
• 進行數據加熱後，文件加載數據明顯提高很是多。

結論

• CDN在數據預熱後實現了網站加速的效果，對比數據預熱先後同事G設備上的性能表現，加速效果大約在5～15倍之間。

從最後的效果效果來看，將文件打開速度由10s級降到將近ms級，確實極大優化了用戶「第一次接觸」的用戶體驗，可以讓用戶有耐心講應用使用下去，也可以在展位上讓觀衆可以使用本身的設備打開服務，對交互和受衆面的提高都具備很是大的好處。

後記

覺得這就完了？後面還有內容，量化說明CDN的加速效果並非這篇文章的主要目的。

「數據預熱」這一名詞時在CDN的原理文章比較少提到的，在獲得第二組測試數據的時候，我就十分困惑的提交了工單，才得知了「數據預熱」這一環節。進一步和工程師詢問得知，AliCloud的CND默認是搶佔式的，就像硬盤與內存的映射關係，使用越頻繁，加速內容在冗餘站點的存放時間與獲取資源也會越多。

所以個人PC所接入的加速站點具備很好的加速效果

而低頻或剛添加的資源默認並不會傳輸到冗餘站點，須要在控制檯手動進行「數據預熱」。且即便預熱後，長時間不使用也會從冗餘站點抹除，被替換掉。固然，從所支付的費用來講，這一搶佔機制是很合理的，畢竟我完成全部測試也只花費了0.26RMB的費用。

在第三組數據中，應該能發現即便數據預熱後，加速效果在不一樣設備間的表現效果也是存在差別的，如在同事C設備上，加載數據都在ms級，而在同事G與與同事L設備上，倒是個位數的s級。細心的讀者也許會發現，我在CDN設備上面都標註了一個地理信息，個人我的PC是湖北、同事G是山西，同事L與同事C是甘肅。（在第二組數據中因爲還不清楚這個概念，當時沒有記錄）

這些地理位置，是AliCloud冗餘加速站點所處的地理位置的信息，這裏一個頗有意思的現象是，以上全部4臺設備都是處在同一個局域網下的4個獨立的設備，3臺Win，1臺Mac，走同一個網關接入因特網，但每一臺設備接入的CDN加速站點都不相同！

兩個同屬甘肅的服務器IP不相同 同一臺設備接入的冗餘站點始終相同

也由於以上緣由，致使他們加速效果存在差別，這一點是讓我很是不理解的，爲何同同一個局域網下的設備接入加速站點的位置卻有如此大的差別？接入冗餘加速站點的規則究竟是怎樣的？這是我一直沒有弄明白的問題，在工單上詢問工程後也沒有獲得明確的回覆，姑且只能擱置於此。

要獲取更多Haytham原創文章，請關注公衆號"許聚龍":