Varnish 的 Super Fast Purger...

Reverse Proxy 的 Cache Infrastructure 在遇到 cache invalidate 都是很討厭的問題,不是不能做,而是效能不太好... 常見的作法是設計成不用 purge 的形式,只要是需要更新,就產生不同的 url,而舊的 url 在沒人 access 後會透過各種 Cache algorithms 自動回收掉,像是 LRU (Least Recently Used) 之類的演算法。

發展久了之後也因此衍伸出很多不同的架構,像是 groupcache 就是假設在同一個 address 的內容永遠不會變的前提。

Varnish Cache 這次發表的東西則是打算從根本問題解決,也就是想辦法讓 purge (cache invalidate) 的成本降低:「Simple scales better and faster in the real world」、「VAC 2.0.3 with high performance cache invalidation API (aka the Super Fast Purger)」。

官方的說法,在大台機器上可以到 60k reqs/sec:

Kristian nonchalantly mentioned that the Super Fast Purger did 60,000 requests per second, on a 6 core Xeon with 36GB memory, traffic over a gigabit network to a single Varnish Cache server, with httperf as test client. But we believe the Super Fast Purger can do a lot more with a little love and tuning.

Squid 效能不好,ATS 的文件很傷,是該找時間來測試看看...

Squid 3.1 的 forward proxy 設定...

因為打算給 portsnap 用,所以得用 Squid 3.1 架 forward proxy,可以避免大量對外抓同樣的資料...

由於是內部的機器,不需要擋 acl,設定起來超簡單... ports 裝完 www/squid31 後,把 squid.conf 寫成:

#
http_access allow all
#
access_log /home/squid/logs/access.log squid
cache_dir aufs /home/squid/cache1 1024 16 16
cache_effective_group squid
cache_effective_user squid
cache_log /home/squid/logs/cache.log
cache_mem 256 MB
http_port 3128

這樣就「會動」了... (先不管效率) 照 squid 的慣例,第一次必須先跑 /usr/local/sbin/squid -z 讓目錄建立出來,後面就是標準的 /usr/local/etc/rc.d/squid start

mCool 方案的帳單...

申請 mCool 方案後第一次收到生效月的帳單,厚厚的一包:

基本月租費率 383 加上 mCool 最高值 299 就是 682,看起來這個方法沒什麼問題。已經幾個月過去了,把想的到的注意事項寫起來:

  • 首先是開通 mCool 方案,並且關閉 3G APN internet 的能力 (避免出事),這兩個設定都可以透過客服幫你處理,請客服關的時候記得順便問什麼時候生效。
  • 另外,請客服幫你設定下次帳單要寄通話明細,如果發生意外的時候總是要有資料才知道發生什麼事情。
  • 除了基本的 APN Proxy 設定外 (這邊就不教學了,網路上很多),再來是裝 Transparent Proxy。這是因為有些應用程式可以直接吃 APN Proxy 設定,但遇到不吃的應用程式就要試著用這套軟體打通...

一時間想到的就這樣...

參考資料: