iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 25
1

前言

看到一篇很神奇的論文:Caching Doesn’t Improve Mobile Web Performance (Much),翻譯一下就是,在手機上的瀏覽器採用 Cache 機制並不會讓瀏覽器快多少。事實上是會快一點,但真的只是一點點。

一個包含 Google 工程師的研究團隊發現,Cache 機制在桌面上瀏覽器去以讓速度進步 34 %,但在手機上瀏覽器卻僅僅 13 %。這很奇怪,真的很怪,Google 工程師心想「我們家的 Chrome 應該大小通吃啊?!」回顧一下我們在「為什麼手機上網速度比較慢呢?」這篇文章中提到的,網路延遲以及載入相關檔案會使得使用者感受到瀏覽器很卡。而 Cache 是指瀏覽器將一些資源暫存起來,下次要用時就不需要再下載,理論上應該很快啊?尤其網路是關鍵的的時候更該是如此?

接下來我們來看看這篇論文做了甚麼研究來解釋這個神奇的現象!

註: 以下的圖片皆來自原始論文


一些先備知識

瀏覽器的流程圖我們已經看很多了,不過今天的多了一個 cache

載下來的資源會存在 cache 以便不時之需。


再來我們看一下載入資源的時程圖

這邊我們定義兩個名詞 Page Load Time(單頁載入時間)和 Critical Path(關鍵路徑)。
所謂單頁載入時間就是當瀏覽器開始下載到一切就緒的時間,通常就是從開始跑到 js 的 onload 被呼叫的時候。
關鍵路徑則是載入過程中所需要的最長路徑。怎麼說呢?因為不相干的東西可以同時一起載,但是如果有關聯性的東西,就必然會有先後順序了,可能是A裡面呼叫B,B再乎叫C。

我們將會使用關鍵路徑分析(critical path analysis)非常適合用在平行化處理的服務上,瀏覽器就非常適合,任何不是關鍵路徑上的優化都不會讓單頁載入時間變短,如同上圖中 png 的時間變短也不會影響關鍵路徑。


建立模型

以上的關鍵路徑可以用一個數學模型表示。

X: 快取再次被使用的比例(cache hit ratio)
K: 關鍵路徑上可以被快取的物件比例
N: 關鍵路徑的網路延遲
C: 關鍵路徑上的計算延遲
f(x): N 和 C 有重疊的時間(極少數狀況剛好N和C並行,通常忽略)

關鍵路徑上的物件導致網路延遲的機率(Pr):
1−Pr(可快取)·Pr(快取可再利用|可快取)
預期的單頁載入時間(E)可以表示成:
E[X]=C+(1−K·X)·N−f(X)

有沒有很神奇!


估計模型

首先來看N和C,我們用以下這張圖的數據來估算:

comp 數字越大代表 CPU 越慢,可以發現 CPU 越差單頁載入時間越長,滿合理的。
再來 x 軸是網路速度,速度越慢載入時間越長,也很合理。

再來是K,一般而言有 65%的物件可以被快取,但只有 20%的物件會再次被使用。所以K就是 0.2。

f(X)通常可以極小,所以在模型中我們可以忽視。

至於X則是我們的操縱變因,也是整個命題的核心,究竟 Cache 到底有沒有效?


實驗

有了模型之後,當然就是做實驗啊!

Web Page Replay(WPR) 是一個紀錄連線一個 URL 所有 request 和 reponse 的裝置,這個東西的目的是製造一個穩定的假想連線。使用方式就是我先用 WPR 連一個網站,記下所有流程,之後實驗都用 WPR 的紀錄來測試。

而 telemetry 就是一個記錄時間的軟體,藉由 WPR 的紀錄來對桌面以及行動裝置的瀏覽器做測試。


實驗結果

測試數據中超過 90% 的網頁可以有超過 90%的物件被快取。理論上這麼高的比例,如果讓快取量增加,速度應該更快吧,因為網路時間是一大因子。

但結果很不幸:

我們可以看到 20% 跟 30% 快取量的載入時間竟然一樣。這邊 30% 有被控制必定包含 20% 的快取。
完全打破我們的想像。

再來看如果是「完美」的 Cache 情況下呢?

縱軸是所有測試的網站所佔的比例,橫軸是縮短時間比例。結果就如同本文開頭說的,桌面版進步 34%,行動版卻只有 13%。

同一張圖還有另外兩個實驗,我們將桌面的 CPU 和 RAM 被限制。
結果我們發現 RAM 被限制不影響結果。
但被限制的 CPU 卻非常接近行動裝置的實驗結果。

於是我們再來看這張圖:

CPU 越慢真的導致單頁載入時間變慢。如同先前假設的。

如果我們讓 Cache 增加 10%看看結果呢?

不幸的,單頁載入速度只快了 1%。證明說 Cache 幾乎不會影響。

這時候我們回到我們一開始的數學模型,X代表關鍵路徑的快取再次被利用的機率,而實驗也證明模型是有道理的,快取量增加對關鍵路徑上的物件影響微乎其微。自然時間也不會縮短。

E[X]=C+(1−K·X)·N−f(X):X非常小的話,那麼(1-K·X) 幾乎還是 1。


結論

所以為什麼 Cache 沒效呢?

我們的模型是 E[X]=C+(1−K·X)·N−f(X),注意這邊C(CPU)和X(Cache)同時影響了這條式子。當C的影響被放大的時候,X的影響就會被弱化。這也是為什麼桌面版瀏覽器有明顯進步,行動版卻沒有。其實行動版的 Cache 也有貢獻,只是被 CPU 吃掉了。

此外 Cache 也不見得一定有幫助,我們在乎的是「關鍵路徑」,要是路徑數量很多,Cache 被平分到各個路徑上,那麼關鍵路徑受惠的程度也就很小。

最後就是 CPU 的技術日新月異,那未來的話,如何讓 Cache 更有效就會是關鍵了!

後記:
這篇用的手機時脈很低,而最新的 iPhone A11 時脈逼近 Macbook Pro 了,在最高效能的情況下,CPU 的影響因子可用又會變小,那這邊的結論就會截然不同。所以可以說這篇的結論是用「中階」款手機,也就是一般市面上的普遍狀況。


希望有幫到大家,大家明天見!


關於作者

劉安齊

軟體工程師,熱愛寫程式,更喜歡推廣程式讓更多人學會


上一篇
瀏覽器平行化
下一篇
再談影響行動裝置瀏覽器速度的因素
系列文
來做個網路瀏覽器吧!Let's build a web browser!35

1 則留言

0
Claire Chang
iT邦新手 5 級 ‧ 2018-01-19 17:53:15

此外 Cache 也不見得一定有幫助,我們在乎的是「關鍵路徑」,要是路徑數量很多,Cache 被平分到各個路徑上,那麼關鍵路徑受惠的程度也就很小。

這邊不太能夠理解,所以意思是說,關鍵路徑越長的反而有CACHE會效益越大嗎?

另外,N: 關鍵路徑的網路延遲,如果是HTTP1.0和HTTP/2在N的表現上會有差異嗎?

路徑有可能很多條,每條長度也不一樣大。可以用機率去想,越多條路徑,越不容易被分到,而至於如果關鍵路徑很長,其他路徑很短,那快取中包含在關鍵路徑的機率也就變大了。所以你講的可能是對的。
N 這邊我不確定他是用哪種協定,但 HTTP/2 一定是比較快,延遲和寬頻都比較優秀。

我要留言

立即登入留言