## 指路牌
* CDN
* 網站靜態資源加速
* 定量展示CDN加速效果
* CDN配置好了但是沒有加速效果？

## 適用場景
* “**第一次接觸**”使用者體驗提升
* 網站具有大量圖片、css、js等靜態資源
* ECS購買了固定頻寬，頻寬成為效能瓶頸

## 環境
* 一個已完成“備案”的域名
> 域名購買後需要實名認證+備案，大概需要花費“**14～20天**”。
* 開通阿里雲CDN服務

## 參考部落格
Web專案聚集地 --- [一文讀懂 CDN](https://mp.weixin.qq.com/s/adMdjBqFiCciOAkjXDJ54Q)
阿里雲 --- [CDN文件](https://help.aliyun.com/document_detail/27112.html?spm=5176.11785003.overview.8.67c8142frmXvNO)

## 背景
我曾接觸過兩個專案，一個是基於web的AR專案，一個是使用了大圖的展示性專案。兩個專案都有一個共同特點：載入速度很慢。慢到什麼地步呢？頁面完全載入完的時間量級均在兩位數（10s左右），極端情況下甚至會達到20s甚至更久。

如此開啟速度對於一款應用的體驗來來說是災難級的，因為不會有一個使用者有耐心等待如此長的時間，web前端針對載入速度慢在技術上具有很多解決方案：如使用一張畫素很低體積很小的圖片先顯示以“安慰”使用者，或使用分批載入等。

但以上兩種方案都無法解決我碰到場景的問題，因為AR專案的js檔案與AR檔案都同樣龐大，以上方案都不能完全挽救兩位數量級載入時間的災難級體驗。

幸運的是兩個專案都是展位性質的，只需要利用瀏覽器自身的快取機制，提前開啟幾次頁面就能將載入時間將時間輕易降到50ms附近，讓觀眾戶完全感覺不到載入的耗時。

但是如此雨來，展示的互動性將變得很受限，因為使用者無法使用自己的裝置親自開啟體驗應用，只能使用講解員手中提前快取好資料的裝置。

我調研CDN的初衷，也是為了嘗試解決以上問題：能夠讓完全沒有快取使用者的裝置在“**第一次接觸**”應用時能夠較快開啟應用，提高互動性。

## 原理&思路
要解決現有的問題，那麼需要先分析一下效能瓶頸到底出在了什麼地方。網頁載入速度慢的根本原因當然是檔案過大，但監控伺服器資源佔用等引數後我將引數鎖定在了兩個：地理位置、頻寬。

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

## 步驟
為了確定上面兩個問題，我選取了專案中的部分檔案作為用例，做了一系列測試，得到三組對比資料如下：

一、境內外ECS對比
![](https://user-images.githubusercontent.com/37465243/63652480-28caa580-c793-11e9-9cfa-885168b1b4a0.png)
> * “行”為該檔案載入耗時，單位為ms、s
> * 時間讀取自Chrome控制檯
> * 禁用了瀏覽器cache，為了避免誤差每次測試前均再一次手動刪除快取圖片與記錄。
> * 每個檔案在一個ECS測試3次，因此每個檔案一共2組，6個資料。
> * AWS的ECS在頻寬上遠比Ali的ECS高，Ali這的ECS的頻寬為固定頻寬5Mbps（也即0.625MB/s）。

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

結論：
由於空間位置原因無法獲取檔案在奧蘭多處的載入耗時，不嚴謹的得出結論：AWS在頻寬上彌補了物理距離的差距，二者速度差異不大。

二、在AliCloud的ECS，使用CDN加速與不使用CDN加速對比
![](https://user-images.githubusercontent.com/37465243/63652481-2e27f000-c793-11e9-9772-81e98fce5d23.png)
> C、D、E三列為先前測試資料
> F、G、H、I列為使用CDN加速後測試資料
> G為同區域網下同事電腦
> H、I為使用手機熱點4G網路下在另一臺裝置Mac上的時間表現

現象
* F列為本人PC，具有非常明顯的加速效果，
* G、H、I三列均沒有任何變快表現，甚至還更慢了......

結論：
* Ali的CDN難道是針對單個IP進行加速，來欺騙消費者的嗎？
> 這個結論當然是錯的，但是資料上又呈現出了以上特點，又是什麼原因導致的呢？繼續往下看

三、在AliCloud的ECS，使用CDN加速，並進行“***資料預熱***”後資料對比
![](https://user-images.githubusercontent.com/37465243/63652484-3122e080-c793-11e9-9041-7deced00cd71.png)
> 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原創文章，請關注公眾號"許聚龍":***
![我的微信公眾號](https://user-images.githubusercontent.com/37465243/63688227-5b2ede00-c839-11e9-9aa9-2b461444f463.png)

定量的CDN加速效果分析

相關文章