指路牌
- CDN
- 網站靜態資源加速
- 定量展示CDN加速效果
- CDN配置好了但是沒有加速效果？
適用場景
- “第一次接觸”用戶體驗提升
- 網站具有大量圖片、css、js等靜態資源
- ECS購買了固定帶寬，帶寬成爲性能瓶頸
環境
- 一個已完成“備案”的域名
域名購買後需要實名認證+備案，大概需要花費“14～20天”。
- 開通阿里雲CDN服務
參考博客
Web項目聚集地 --- 一文讀懂 CDN
阿里雲 --- CDN文檔
背景
我曾接觸過兩個項目，一個是基於web的AR項目，一個是使用了大圖的展示項目。兩個項目都有一個共同特點：加載速度很慢。慢到什麼地步呢？頁面完全加載完的時間量級均在兩位數（10s左右），極端情況下甚至會達到20s甚至更久。
如此打開速度對於一款應用的體驗來來說是災難級的，因爲不會有一個用戶有耐心等待如此長的時間，web前端針對加載速度慢在技術上具有很多解決方案：如使用一張像素很低體積很小的圖片先顯示以“安慰”用戶，或使用分批加載等。
但以上兩種方案都無法解決我碰到場景的問題，因爲AR項目的js文件與AR文件都同樣龐大，以上方案都不能完全挽救兩位數量級加載時間的災難級體驗。
幸運的是兩個項目都是展位性質的，只需要利用瀏覽器自身的緩存機制，提前打開幾次頁面就能將加載時間將時間輕易降到50ms附近，讓觀衆戶完全感覺不到加載的耗時。
但是如此雨來，展示的互動性將變得很受限，因爲用戶無法使用自己的設備親自打開體驗應用，只能使用講解員手中提前緩存好數據的設備。
我調研CDN的初衷，也是爲了嘗試解決以上問題：能夠讓完全沒有緩存用戶的設備在“第一次接觸”應用時能夠較快打開應用，提高互動性。
原理&思路
要解決現有的問題，那麼需要先分析一下性能瓶頸到底出在了什麼地方。網頁加載速度慢的根本原因當然是文件過大，但監控服務器資源佔用等參數後我將參數鎖定在了兩個：地理位置、帶寬。
接下來我們就來看看CDN到底能不能實現加速，以及能夠加速到什麼地步？
步驟
爲了確定上面兩個問題，我選取了項目中的部分文件作爲用例，做了一系列測試，得到三組對比數據如下：
一、境內外ECS對比
- “行”爲該文件加載耗時，單位爲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加速對比
C、D、E三列爲先前測試數據
F、G、H、I列爲使用CDN加速後測試數據
G爲同局域網下同事電腦
H、I爲使用手機熱點4G網絡下在另一臺設備Mac上的時間表現
現象
- F列爲本人PC，具有非常明顯的加速效果，
- G、H、I三列均沒有任何變快表現，甚至還更慢了......
結論：
- Ali的CDN難道是針對單個IP進行加速，來欺騙消費者的嗎？
這個結論當然是錯的，但是數據上又呈現出了以上特點，又是什麼原因導致的呢？繼續往下看
三、在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原創文章，請關注公衆號"許聚龍":