HHVM 2.3.0 支援 FastCGI...

HHVM 官方的 blog 上看到 2.3.0 的消息:「HHVM 2.3.0 and Travis CI」。

GitHub 上的「FastCGI」這頁就有提到要怎麼透過 FastCGI 界面跟 Apache 配合,熟悉 nginx 的人也應該可以輕鬆對應過去。

另外一個重要的事情是 Travis CI 支援 HHVM 了,可以看到大量的專案加上 HHVM 測試:YiiSlimphpBBJoomlaDoctrineCodeIgniterIdiormPHPUnitParis

既然支援 FastCGI 了,來找機會測試看看...

Google Chrome 上預防 Clickjacking 的套件...

Gene 寫的「如何在你不知情被自動加入粉絲團的秘技, 以 "粉你的" 作示範」這篇裡面用到的技巧叫做 Clickjacking (點擊劫持)。

Facebook 有給出「What is clickjacking?」的說明,不過相當白話 (而且沒有幫助 Orz)。

技術上的解釋是,其中一種實作是在要點擊的對象上加上一層「透明的」DOM 物件,當 click 時就會點到該物件。目前最常見的是 Facebook 的 Like 按鈕。(i.e. Gene 寫的那篇)

Google Chrome 上可以用「Clickjacking Reveal」這個套件:

This extension tries to warn you if it found clickjacking technique on the page you are viewing.

Tired because of webpage tricks you into clicking social network buttons? This extension will try to detect those hidden bad buys and force them to show themselves.

效果是這樣:(範例出自「胖妞變身大美女 甩肉40斤練出腹肌」這篇)

Facebook 發展的 RocksDB...

Facebook 利用 Google 所發展的 LevelDB 開發了 RocksDB,跟 LevelDB 相同,仍然是 persistent key-value store,重點在於能夠使用多個 CPU 增加效能的能力:

RocksDB builds on LevelDB to be scalable to run on servers with many CPU cores, to efficiently use fast storage, to support IO-bound, in-memory and write-once workloads, and to be flexible to allow for innovation.

Performance Benchmarks 這邊可以看到效能的數據,主要都是跟 LevelDB 比較。比較的時候不只是寫了快了多少,而是包含原理都有寫出來。

source code 在 GitHub 上可以翻到:facebook/rocksdb,除了 source code 外,還發現裡面有 PATENTS 這個檔案,裡面針對專利的部份給予豁免... 好像很少看到?

Facebook 的 InnoDB patch 讓 table scan 速度變快...

Facebook 的 Database Engineering team 實作了 patch,讓 InnoDB 在 table scan 的速度大幅提昇:「Making full table scan 10x faster in InnoDB」。

第一個 patch 叫做 Logical Readahead。第二個 patch 是針對 async i/o 的改善 (Submitting multiple async I/O requests at once)。

引用文章內的幾段話就知道這幾個 patch 的功力了:

Logical backup size is much smaller. 3x-10x size difference is not uncommon.

備份出來的資料會變小,而且宣稱 1/3 到 1/10 不是罕見情況... -_-

With logical readahead, our full table scan speed improved 9~10 times than before under usual production workloads. Under heavy production workloads, full table scan speed became 15~20 times faster.

然後 table scan 的速度會快非常多... 10 倍?如果是平常就很操的 database 會更明顯?

如果這幾個 patch 如果沒有什麼問題,可以預期會被 merge 到 PerconaMariaDB,至於 Oracle 官方的 source tree... 有的話當然很好,沒有的話也很正常?

移除 Remove Facebook Redirections...

Google Chrome 裝上 Remove Facebook Redirections 可以避免 Facebook 重導,加減提高些隱私性...

不過最近發現當 Facebook 捲頁捲很長時會變得爆慢,但網路上好像沒有人提到這個問題?看起來應該是我的某個 extension 造成的,測了老半天發現是這個 extension 的問題 :o 然後身為工程師的直覺,這八成是每次增加元素後直接對整個 document 全掃一次造成的...

翻 source code 後 (直接到 Default/Extensions/onhdomkbnapoacbialllfpbcckckidck/1.2_0/ 裡的 RemoveFacebookRedirections.js 翻) 可以發現 huntForLinks() 果然就是這樣做...

先移除掉再說 @_@

MySQL 4.0 與 MySQL 5.6 的比較...

FacebookMySQL 老大 Mark Callaghan 把 MySQL 古董版本 4.0 拿出來跟現在的 5.6 比較:「MySQL 5.6 versus 4.0 for a read-only workload」。

可以看到 MySQL 在 Read-Only 情況的效率進步 (Read-Only 的 lock issue 比較容易被克服,拿來比較會比較好看),這效能根本不能比 XDDD

(要注意圖片的 y 軸不是 0 為起點)

維基百科英文版與德文版的資料庫 (條目最多的兩個語言) 從 MySQL 轉移到 MariaDB 了...

維基百科官方宣佈兩個條目最多的資料庫 (英文與德文) 已經從 MySQL (有 FB patch 的版本) 轉移到 MariaDB 5.5 了:「Wikipedia Adopts MariaDB」。

維基百科的資料庫從 MySQL 4.0 升級到 MySQL 5.1 時花了不少功夫轉換 (可以想像出來,這兩個版本的差距...),然後這次再到這次的 MariaDB 5.5 就輕鬆不少。

在文章內有提到因為維基百科是 read-heavy site,大多數前端的負荷都在 squid 層擋下來,實際到後端的量則是再透過 Redismemcached 打散負荷。不過即使做了這麼多層 cache,英文版資料庫在尖峰時間還是有 50k qps 的量在跑。

尖峰時間這 50k qps 的量有 80% (也就是 40k qps) 是打散到兩台不同地點的 slave 上,平均的 query response time 是 0.2ms,95% 則是 50ms (好高),其他的 20% 是寫入 master 需求,或是因寫入 master 時需要一致性 (也就是要避免 replication lag 造成的問題)。

這次升級到 MariaDB 5.5.30 是先準備一台新機器,然後在 load balancer 上換掉其中一台 slave (先建後拆),如果 MariaDB 真的有問題也可以馬上 rollback 回來。另外用 pt-query-digest 取樣分析 query 的狀況。

這是成果:

For our most common query type, 95th percentile times over an 8-hour period dropped from 56ms to 43ms and the average from 15.4ms to 12.7ms. 50th percentile times remained a bit better with the 5.1-facebook build over the sample period, 0.185ms vs. 0.194ms. Many query types were 4-15% faster with MariaDB 5.5.30 under production load, a few were 5% slower, and nothing appeared aberrant beyond those bounds.

第一台觀察一陣子沒問題後,接下來一台一台換掉。然後發公告慶祝 :p

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 的工程師們想要解決什麼問題。