Firefox 4.0 中緩存機制的重大改進

Mozilla 官方看來是注意到「硬碟緩存」的重要性了

原本 Number of entries 的限制為 8192
從 4.0 開始，提升兩倍變成 16384

現在每小時版的 beta 12，似乎更加大了上限值 (應該是之前這個版本就開始)
以我自己的使用情況是目前數值為 43906
使用硬碟空間 660M 左右 (在選項裡面開啟緩存管理機制，上限1G)
不知道是不是已經變成無上限了

其他瀏覽器的快取機制如何不是很清楚
但在網路資料快取的改進上 Firefox 或許領先了一步

PS.沒有比從硬碟直接抓網頁資料來的更快的技術了
   之前因數量上的限制，容易將「還可再利用」的網頁資料覆蓋過去 (圖片、js、txt)
   所以整個網頁的讀取就要重新整個 running 一遍 (封包千里迢迢跑來跑去)
   畢竟現在硬碟便宜，拿個 5G ~ 10G 做快取也不過份

PS .Cache 資料夾的結構也有變化，原本是把資料壓縮後直接放進去不分類
   現在貌似變成跟 Squid Cache 一樣，建立一堆資料夾下去分再放進去
   不知道這是不是比較有效率方式?

勾上之後貌似緩存的資料保存數量就沒有上限，長遠來看是有幫助的，原因在一樓。

待過 Yahoo 跟 Google 的工程師也認為用 5 ~ 10G 保存緩存不過分
http://www.stevesouders.com/blog/2010/0 ... r-caching/

另外我認為應該是匹配 URL 地址，這樣才科學，針對不同的網站相同的圖片
直接從硬碟讀取無疑是最有效率的做法，緩存的搜尋速度應該比想像中的還要快
以老牌的快取服務企 Squid Cache 為例
通常在 0.01 秒的範圍左右即可命中並返回目標物件給瀏覽器 (緩存 10G 以上)
相信 Firefox 這方面的技術應該不會差 Squid 太多 (結構也越來越像了)

我去年開始使用 Squid Cache 後，目前 Squid 的命中率約 33% ~ 35% 左右 (僅一個人使用)加上 Firefox 本身的快取，應該超過 50%
這證明了使用快取對瀏覽網頁是非常高效的手段之一
也就是有二分之一以上的東西都是直接從硬盤上抓回來的

上面 Google 工程師的文章也提到目前瀏覽器對緩存的使用率遠遠低於平均值
也就是緩存的「再利用率」不夠，如果能提高網民對緩存的使用率，相信對
整個網路會有正面的幫助，最直接的就是減少不必要的流量封包

arch7819：个人用户, 使用 5G 缓存毫无必要.

HTTP 本身提供了 Expires, ETags, Last-Modified, Cache-Control 作缓存的相关控制.
视频这类大型文件只会使用一遍的通常都会有 Cache-Control: no-cache, 因为缓存它的性价比太低.

缓存的通常是图片, 脚本, 样式表等这些小的静态文件.
如果这些文件达到了5G, 那么我可以肯定其中99%的实体都是过期的,
缓存一个过期的项目毫无意义.

缓存查找使用哈希, 代价几乎为零的, 这个不需要担心. 需要担心的是缓存的命中比例, 如果1G的缓存只被命中了100K, 很明显还不如不去缓存.
 
比较好的解决方案是使用两代缓存, 第一代捕获, 第二代存储, 使用锁相的算法控制容量和命中的平衡.
但是这类算法通常只使用在比较苛刻的限制环境下的, 比如java代码运行时编译.回到原帖

所以我才架了個 Squd 緩存伺服器，這個伺服器可以控制各類物件緩存的時間
原則上是讓圖片、腳本類保存較長的時間
讓 txt、php、html 等需及時更新的頁面保存較短時間或者直接使用頁面默認的時間

上面也提到了，我一個人用，Squid 有 30% 左右的命中率，加上 Firefox 本身的快取
加總起來應有 50% 以上，也就代表平均一半的資料是直接從硬盤上抓取的

以一個人，短時間內的上網體驗來看，5G 的確是很多，但長期下來
以 80/20 法則的觀點來看，現階段的瀏覽器緩存的機制並沒有做到最高效的緩存處理，除了空間的限制以外
另外一個就是緩存的算法，也就是什麼東西該緩存什麼不該
又該緩存多久時間等等，而這方面，Firefox 4.0 貌似進步不少。

只用內存緩存貌似效率是最差的

剛剛發現增加了這個選項
Tell web site I do not want to be tracked
有人知道做什麼用的嗎?

以目前的設計來看，Number of entries 最大值貌似為 2097152
全部用滿大約是 30G 以上，不過在選項裡面的最大值限制在 1024M
所以實際上只能使用 50000 條左右的 entry
而 about:config 裡面可以修改 1024M 的上限值，但改了有沒有效果還有待進一步確認