Tag Archives: cache

Pinterest 對 ZooKeeper 的用法

在「ZooKeeper Resilience at Pinterest」這篇文章裡面,Pinterest 的人說明內部是怎麼使用 ZooKeeper,其中對我來說最重要的是這張圖:

程式不直接接觸 ZooKeeper 取得資料,而是透過 daemon 寫到 local disk 的資料取得。這樣當 ZooKeeper 失敗時仍然可以保持一定的服務 (因為 local disk cache),而避免服務中斷。

當然,這跟資料的性質有關,不是所有的資料型態都可以接受 cache。這種解法常常是在穩定性不是可以自己控制 (這個例子裡是 ZooKeeper),而且遇到問題時不希望整個服務就爆炸...

但這個思路每次看過每次都會忘記,寫下來不知道會不會比較容易想起來 :o

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 的文件很傷,是該找時間來測試看看...

Facebook 的 Memcache 架構...

NSDI '13Facebook 的工程師有講到 Facebook 內的 Memcache 的架構:「Scaling Memcache at Facebook」,有影片可以看,也有 PDF 投影片可以下載。

其實 2013 年這次的 conference 提到的架構以前就有提過了... 雖然一時間找不到之前提到架構的投影片,但還是可以配合著以前提到各種架構的文章與投影片看出 Facebook 怎麼利用 Memcache 架構 cache layer:

Facebook 會這樣設計 Memcache 架構,跟 Facebook 用 PHP 的方式有關,是在 PHP 的限制下想辦法爭取效率的作法。

不過這些投影片裡的資料畢竟是有年代了,現在的 memcached 改善了很多,跟當年的情況不太一樣,看之前的投影片最好知道當時 memcached 有哪些問題會比較能理解 Facebook 的工程師們想要解決什麼問題。

W3 Total Cache 0.9.2.6 的災情慘重...

W3 Total Cache 出了新版,升級上去後 WordPress 就爛掉了,最後是先 downgrade 到 0.9.2.5,然後再進系統把 W3 Total Cache 完全 deactive...

有看到升級資訊的人可以先等一下,這次的 0.9.2.5 到 0.9.2.6 不是 minor version upgrade:

-rw-r--r--   1 gslin  staff   854455 Feb  6 04:12 w3-total-cache.0.9.2.3.zip
-rw-r--r--   1 gslin  staff   915186 Feb  6 04:11 w3-total-cache.0.9.2.4.zip
-rw-r--r--   1 gslin  staff   915384 Feb  6 04:02 w3-total-cache.0.9.2.5.zip
-rw-r--r--   1 gslin  staff  1292961 Feb  6 04:11 w3-total-cache.0.9.2.6.zip

看起來這個作者沒什麼版本號的觀念,之後升級他的東西小心一點... XD

Google 對字串處理的最佳化

Google Research 上看到 Google 針對字串處理最佳化問題所發的論文:「Automated Locality Optimization Based on the Reuse Distance of String Operations (PDF)」。

大原則是想辦法善用 L2/L3 cache,這沒什麼特別的,比較有趣的地方是解決方案,除了自動化的方式外,另外還有工具「提醒」撰寫程式的人,另外還有一些數據以及 code name 可以看...

W3 Total Cache 安全性問題...

在「W3 Total Cache Implementation Vulnerability」這篇說明了 WordPress 知名外掛 W3 Total Cache 的安全性問題,原來的在通報在 Full Disclosure Mailing List 上:「WordPress Remote Exploit - W3 Total Cache」。

當沒有 opcode cache (像是 APC) 而使用 disk DB cache 時,會有安全性問題。

除了關掉 DB cache 以外,目前的 workaround 建議是針對 /wp-content/w3tc/dbcache 擋掉,像是用 .htaccess 擋:

#
deny from all

用 JavaScript 遠端攻陷 Intel Core2Duo...

Hacker News 上看到了「Intel Core2Duo cpu cache controller bug PoC」,透過 JavaScript 遠端攻擊 Intel Core2Duo,直接突破所有 application & OS 保護機制... exploit 說明裡提到測過 Intel Core 2 Duo T5750Intel Atom N270 這兩顆 CPU。

另外,從 exploit 給的資料中,可以找到 Kris KasperskyHITB 2008 給出來的 PDF:「Remote Code Execution through Intel CPU Bugs」。

居然用 JavaScript 戳...

Update:很像是假的:「http://news.ycombinator.com/item?id=4246338」。

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

WordPress plugins 安全性問題

TechCrunch 上看到 WordPress.org 強制所有 WordPress.org 的使用者更新密碼 (不是 WordPress.com):「WordPress.org Forces Password Resets Due To Compromised Plugins」。

起因是 AddThisWPtouch 以及 W3 Total Cache 這三個 plugin 有異常 commit 塞入 backdoor code。(瞬間就中兩槍)

這幾天有更新 plugin 的人最好趕快看一下... 慘啊 :/