Firefox 48 將引入 Multi-process 模式

現在是 Firefox 47,也就是下個版本就會引入 Multi-process 模式了:「Firefox 48 finally enables Electrolysis for multi-process goodness」。

Multi-process 模式也就是 Electrolysis,這對權限的分離 (sandbox) 以及效能的提昇有著顯著的幫助:

Electrolysis functionality hosts, renders, or executes web related content in background child processes which communicate with the "parent" Firefox browser via various ipdl protocols. The two major advantages of this model are security and performance. Security improvements are accomplished through security sandboxing, performance improvements are born out of the fact that multiple processes better leverage available client computing power.

這算是個開頭,地基打出來以後,之後就可以拆更多東西到其他的 child process。

Percona 對 mysql_query_cache 的測試 (以 Magento 為例)

Percona 的人以現在的觀點來看 mysql_query_cache:「The MySQL query cache: Worst enemy or best friend?」。

起因主要也是懷疑 query cache 是 global mutex 在現在的硬體架構 (主要是 CPU 數量成長) 應該是個負面的影響,但不確定影響多少:

The query cache is well known for its contentions: a global mutex has to be acquired for any read or write operation, which means that any access is serialized. This was not an issue 15 years ago, but with today’s multi-core servers, such serialization is the best way to kill performance.

這邊就有點怪了,PK search 應該是個位數 ms 等級才對 (一般 EC 網站的資料量都應該可以 memory fit),不知道他是怎麼測的:

However from a performance point of view, any query cache hit is served in a few tens of microseconds while the fastest access with InnoDB (primary lookup) still requires several hundreds of microseconds. Yes, the query cache is at least an order of magnitude faster than any query that goes to InnoDB.

anyway,他實際測試兩個不同的 configuration,首先是打開 query cache 的:

再來是關閉 query cache 的:

測試的方式在原文有提到,這邊就不抄過來了。測試的結果可以看到關閉 query cache 得到比較好的 thoughput:

Throughput scales well up to somewhere between 10 and 20 threads (for the record the server I was using had 16 cores). But more importantly, even at the higher concurrencies, the overall throughput continued to increase: at 20 concurrent threads, MySQL was able to serve nearly 3x more queries without the query cache.

跟預期的差不多,硬體的改變使得演算法也必須跟著改,不然就會遇到問題...

支援多 CPU 的 ab:wrk

在「wrk」這邊看到 wrk 這個工具:「Modern HTTP benchmarking tool」。

利用 multi-threading 與 epoll/kqueue 撐出效能:

wrk is a modern HTTP benchmarking tool capable of generating significant load when run on a single multi-core CPU. It combines a multithreaded design with scalable event notification systems such as epoll and kqueue.

MySQL 的 Parallel Replication

Multithreaded Replication to the Rescue」這篇提到了 Replication 的 Parallel Worker 機制。

作者給了平行的數量對 replication lag 的影響:

可以看得出來 Parallel Worker 機制對 Replication Lag 改善頗大,不過作者在 comment 提到中雷了:「MTS breaks in after restart」。

對於還在使用 traditional master-slave 架構的人可以參考看看。

AWS 推出信用卡式的 MFA

AWS 推出信用卡式的 MFA:「A Convenient New Hardware MFA Form Factor」。

一樣是跟 Gemalto 合作。相較於之前掛在鑰匙圈上變得更容易收納 (可以放到皮夾內):

實體的 OTP 還是比 app 形式的安全強度好,變成信用卡形式後應該再弄一片來玩玩...

Xiph 講數位訊號...

Xiph 是個網路多媒體相關的 open source 組織,前陣子放了教學影片,介紹多媒體的理論:「Xiph.org: Video」,目前每一集都大約半小時,可以下載下來或是直接在網站上看。

第一課「Episode 1: A Digital Media Primer for Geeks」從數位訊號開始講,包括影像與聲音。第二課「Episode 2: Digital Show & Tell」則是介紹聲音的部份 (包括數位與類比)。

有興趣可以去看看 :p

MySQL 平行執行的 Replication...

MySQL Replication – Multi-Threaded Slaves (Parallel Event Execution)」這篇在講 MySQL 5.6 的 multi-threaded replication。

在文章裡提到,在 5.6.3 之前的版本,MySQL replication 都是 single-threaded,所以當 master 可以充分發揮多 CPU 能力時,slave 仍然要一個更新跑完才會跑下一個更新。

舉例來說,假設 master server 上有兩個 thread 在跑:

  • thread 1 正在執行 UPDATE table1 SET foo = 0 WHERE ...; (SQL 1,假定是 CPU bound,需要跑 100 秒)
  • thread 2 正在執行 UPDATE table2 SET bar = 1 WHERE ...; (SQL 2,也假定是 CPU bound,也需要跑 100 秒)

假設 thread 1 先執行完,這時候 slave 就會在跑完的時候收到 SQL 1,然後把資料同步進去。等到 100 秒過去後,再跑 SQL 2,再花 100 秒。這導致了最少 100 秒的 replication lag (master 與 slave 不同步的時間)。

在 master server 執行時會是這樣:

兩個 SQL query 可以同時跑。

到了 slave 時,在 MySQL 5.6.3 之前的 replication 會變成這樣:

可以看到還是得先執行 SQL 1 再執行 SQL 2,所以最長會有 200 秒的 replication lag。

而 5.6.3 之後支援 multi-threaded replication,可以用 slave_parallel_workers 指定平行執行 SQL query 的數量,這讓 master server 與 slave server 之間的 replication lag 降低不少:

在收到同步的 SQL 指令後就可以同時跑,這讓 replication lag 降到 100 秒。

不過還是要提,如果希望把資料同步問題降到最低,那麼 Galera Cluster 可以解的更徹底,不論是寫入的那台 master server,或是其他的 master server (在 Galera Cluster 架構裡都是為 master),一律都是同步執行:

不會有 master server 與 slave server 不同步的問題,可以減少很多 application 層的麻煩...

RAID5 會遇到的 Multi-disk failure 問題

How multi-disk failures happen」這篇畫了不少圖解釋在 RAID5 上面偶而會遇到的 Multi-disk failure 問題 (RAID6 也會,風險比較低而已)。

RAID 5

平常壞軌時,RAID 系統不一定會發現,直到 RAID rebuild 時讀過所有的磁區,系統才發現其他壞軌,造成第二顆被標為損壞... (推論到 RAID6 的情況就是再發生一次)

這在 I/O 比較頻繁的 RAID 比較不容易發生 (因為在量小的時候就容易偵測到)。

對於比較閒的系統,應該放個 cron 跑 dd if=/dev/XXX of=/dev/null 嗎?:p

用 Lbzip2 解壓縮

手上抓了幾個 .bz2 的檔案要 bzcat 出來 pipe 丟給 Perl script 跑,用系統預設的 bzip2 發現速度卡在解壓縮,而不是 Perl script...

用 parallel 與 bzip2 當關鍵字到 apt-cache 裡面找,有找到兩個套件:Lbzip2Pbzip2,都裝起來後測解壓縮的功能,發現 Pbzip2 解壓縮時沒有辦法利用到多核心的優勢,而 Lbzip2 則是很順利的超過 100%,輸出結果讓 Perl script 也吃滿 CPU resource...

如果是壓縮時需要壓縮率,還是用 xz 就好...