Netflix 對 Landing Page 的效能改善計畫...

幹掉 React (噗):

官方帳號丟戰文出來... 後面就有人開始亂 XDDD

不過先拉回來看... 依照說明,其他頁面都還是跑 React,只有 Landing Page 被改寫,看起來 Landing Page 的 TTI (Time to Interactive) 是他們的 KPI,所以就被拿出來另外處理了...

當然也有可能有其他的陰謀論 (而且我覺得可能性是在的):因為之前 React 的專利問題,變成之後 Facebook 如果真的出手提出告訴,會以惡意侵權來告 (因為鬧這麼大以後,沒有理由裝作不知道了)。這次只換 Landing Page 可以當作是試水溫練功 (累積 migration 的經驗),後續再換內頁...

Amazon Aurora (MySQL) 推出的 Asynchronous Key Prefetch

Amazon Aurora (MySQL) 推出新的效能改善,可以改善 JOIN 時的效能:「Amazon Aurora (MySQL) Speeds Join Queries by More than 10x with Asynchronous Key Prefetch」。

看起來像是某個情況的 optimization,將可能的 random access 換成 sequential access 而得到大量的效能:

This feature applies to queries that require use of the Batched Key Access (BKA) join algorithm and Multi-Range Read (MRR) optimization, and improves performance when the underlying data set is not in the main memory buffer pool or query cache.

其實記憶體還是最好用的加速器,能加大硬拼就先硬拼... XD

InnoDB 的 MVCC 繁忙時的效能問題

Facebook 上看到 Percona 的人修正了 InnoDB 的 MVCC 在繁忙時會有 O(n^2) 的效能問題:

MySQL 官方的 bug tracking system 是「InnoDB's MVCC has O(N^2) behaviors」這個,可以看到給的重製範例是在 transaction 內大量塞 INSERT 進去後,另外一個 transaction 使用 secondary index 就會受到影響。

裡面也有提到「Secondary index updates make consistent reads do O(N^2) undo page lookups」,雖然修正了,但看起來跟當時實做的規劃有關?所以導致許多地方都是 O(n^2)...

這個 bug 感覺是批次作業的行為?因為批次作業可能會用 transaction 包起來,一次寫入萬筆資料後再 COMMIT 進去。而這個行為很有機會觸發這個 bug,導致影響到線上的服務...

nvm 換 n

前幾天在 Twitter 上抱怨 nvm 很慢,導致 Zsh 開起來很頓 (然後也同步到 Facebook 上):

原因在於 .bashrc 或是 .zshrc 內初始化 nvm 時會呼叫 npm config get prefix,而這個命令很慢:「`npm config get prefix` takes incredibly long (7 - 70 seconds) #14458」。

後來在 Facebook 的留言處有朋友提了幾個方案... 其中一個是 n,花了些時間看軟體架構,有夠簡單... XD 對於不是拿 Node.js 開發的人應該是夠用了 (我只拿來跑一些用 Node.js 寫的工具)。

整個軟體就一個 shell script,把他丟進 ~/bin/ 裡面 (我有把 ~/bin/ 放到 PATH 裡),就可以用了。透過 N_PREFIX 設定他的基地 (預設是 /usr/local,我是設成 $HOME),剩下就跑 n lts,他就把 nodenpm 兩個檔案裝好給你用。

路徑的部份要自己設定,將 $N_PREFIX/node_modules/.bin 放進 PATH,這樣安裝起來的模組如果有可執行工具可以用才能直接跑 (像是 gulp.js 的命令)。

另外,之所以會說不適合開發者用的部份,是因為 module 是跨版本共用的 (切換 node 版本時就是用另外一個版本配上去 XD),所以比較不適合開發者使用...

PHP 7.2 的效能改善

作者在「PHP 7.1 vs 7.2 Benchmarks (with Docker and Symfony Flex)」這邊拿 Symfony 測試 PHP 7.2 的效能,發現效能提昇主要來自於多個連線時的情境:

前面的數字是前端頁面 (用了 Twig),後面的數字是純 API 呼叫。都可以看出 conc = 1 時其實沒有顯著差異,但只要有多個連線同時存取時,效能的提昇就會展現出來。對於繁忙的站台感覺會有不少幫助...

作者的猜測是 opcache 模組的改善,也就是在這段提到的:

- Opcache:
  . Added global optimisation passes based on data flow analysis using Single
    Static Assignment (SSA) form: Sparse Conditional Constant Propagation (SCCP),
    Dead Code Elimination (DCE), and removal of unused local variables
    (Nikita, Dmitry)

Branchless UTF-8 解碼器

看到「A Branchless UTF-8 Decoder」這篇,先來回憶一下「非常經典的 UTF-8...」這篇,以及裡面提到的 encoding:

因為當初在設計 UTF-8 時就有考慮到,所以 decoding 很容易用 DFA 解決,也就是寫成一堆 if-then-else 的條件。但現代 CPU 因為 out-of-order execution 以及 pipeline 的設計,遇到 random branch 會有很高的效能損失,所以作者就想要試著寫看看 branchless 的版本。

成效其實還好,尤其是 Clang 上說不定在誤差內:

With GCC 6.3.0 on an i7-6700, my decoder is about 20% faster than the DFA decoder in the benchmark. With Clang 3.8.1 it’s just 1% faster.

而後來的更新則是大幅改善,在 Clang 上 DFA 版本比 branchless 的快:

Update: Björn pointed out that his site includes a faster variant of his DFA decoder. It is only 10% slower than the branchless decoder with GCC, and it’s 20% faster than the branchless decoder with Clang. So, in a sense, it’s still faster on average, even on a benchmark that favors a branchless decoder.

所以作者最後也有說這是個嘗試而已 XD:

It’s just a different approach. In practice I’d prefer Björn’s DFA decoder.

PyPy 5.9 支援 Pandas 與 NumPy 了

PyPy 5.9 支援 machine learning 常用的 PandasNumPy 了:「PyPy v5.9 Released, Now Supports Pandas, NumPy」,包括 2.7 與 3.5 的相容版本:

The PyPy team is proud to release both PyPy3.5 v5.9 (a beta-quality interpreter for Python 3.5 syntax) and PyPy2.7 v5.9 (an interpreter supporting Python 2.7 syntax).

對於使用 Python 大量計算的人來說可以進場測試了 XD

PostgreSQL 10 發表

PostgreSQL 10 發表,有不少重要的功能 (進步):「PostgreSQL 10 Released」。

首先提到的是 Logical Replication:

Logical Replication - A publish/subscribe framework for distributing data

以往內建的 replication 是 block level change (同步哪個 block 改變的內容),對於版本不同的 PostgreSQL 就會痛。所以在 10 之前,想要處理 PostgreSQL 版本不同的問題都會使用第三方套件 (一種常見的情境就是資料庫的版本升級)。在 10 內建支援 Logical Replication 後就不需要掛其他套件了:

Logical replication extends the current replication features of PostgreSQL with the ability to send modifications on a per-database and per-table level to different PostgreSQL databases. Users can now fine-tune the data replicated to various database clusters and will have the ability to perform zero-downtime upgrades to future major PostgreSQL versions.

於是就可以達到 zero-downtime upgrade,這對於商業維運考量是個很重要的進展。

另外一個是 Improved Query Parallelism (在 9.6 就有,現在又再改善了),針對可平行化的 CPU-bounded SQL query 可以利用多 CPU 大幅加速,這點也是目前在 MySQL 上還沒看到的:

PostgreSQL 10 provides better support for parallelized queries by allowing more parts of the query execution process to be parallelized. Improvements include additional types of data scans that are parallelized as well as optimizations when the data is recombined, such as pre-sorting. These enhancements allow results to be returned more quickly.

上面提到這兩點其實對於某些需求是相輔相成的。

因為很多報表分析是可平行化的 CPU-bounded SQL query,但以前在 RDBMS 都不能被平行運算,於是很多單位就會想要倒出來到其他類型的資料庫運算 (以現在比較紅的產品,像是 Amazon RedshiftAmazon Athena,或是 BigQuery,甚至是丟進 ELK 裡)。但你用 PostgreSQL 又會痛在沒辦法很方便的把資料同步拉出來... (於是就會稍微妥協,用 cron job 每天倒資料)

現在 10 的這兩個功能剛好從兩個面向解決:一個是對於剛開使用 PostgreSQL 的人,他們可以繼續只用 PostgreSQL 撐久一點,因為報表需求的 SQL query 快很多;另外一方面也讓目前用 cron job 每天倒資料的人有了同步的選擇 (用 replication 同步到其他系統上)。

再來是 Quorum Commit for Synchronous Replication 這個功能,把分散式架構中需要「正確性」的底層技術做起來:

PostgreSQL 10 introduces quorum commit for synchronous replication, which allows for flexibility in how a primary database receives acknowledgement that changes were successfully written to remote replicas. An administrator can now specify that if any number of replicas has acknowledged that a change to the database has been made, then the data can be considered safely written.

整體來說,PostgreSQL 10 有非常多進步,而且這些進步對於商業營運考量都很有幫助...

MySQL 8.0-rc 的效能測試

Oracle 的 Dimitri KRAVTCHUK (dim) 做了測試,整理出 MySQL 8.0-rc 與其他版本效能的比較:「MySQL Performance : 2.1M QPS on 8.0-rc」。

不過先不管 MySQL 8.0-rc,這個測試其實也在說 MySQL 在 5.6 到 5.7 的過程中,對於高階伺服器效能改善非常的多 (有非常多 CPU core 的機器):

就更不用說 5.5 版 (甚至已經沒支援的 5.0 & 5.1),差距就更大了...

最新的 Firefox 56 對 AES-GCM 效能的改善

昨天釋出的 Firefox 56 對於 AES-GCM 在老電腦上改善了不少效能:「Improving AES-GCM Performance」。

首先是 Firefox 自己的數據分析,可以看到 AES-GCM 佔目前加密連線裡的大宗,再來是 AES-CBC:

先以 Linux 64bits 環境的數據來看,Firefox 56 的 NSS 3.32 大幅改善了老電腦的效能 (不支援 AES-NI 硬體加解密的 CPU,甚至是不支援 PCLMUL 的 CPU,以及不支援 AVX 的 CPU):

在 Linux 32bits 環境上則是連預設值大幅改善,不過用的人應該少很多了:

Windows 下則是因為 64bits 或是 32bits 都有足夠的使用者,所以平常就花了不少力氣。但也可以看出對於老電腦的速度提升:

Mac (64bits only) 算是這次比較大的提升,連新電腦的預設值都大幅變快:

加上之後陸續的改善 (尤其是下一版 Firefox 57 的 Project Quantum),這幾版應該會拉出不少效能...