Tag: benchmark

Internet 上的 3rd party js 的情況

在 Twitter 上看到這則：

裡面提到了「patrickhulce/third-party-web」的分析 (作者是從 HTTP Archive 的資料分析)，裡面依照不同種類的 3rd party js (像是 ad，或是 social element，或是分析工具) 需要執行的時間，以及使用的站台數量。

Social 那邊意外看到 PIXNET 有上去，然後速度只比 Disqus 快一些，應該是沒有 optimize 的關係。

如果整體一起看的話 (總和花費時間)，可以看到 Google 各項產品都在最前面，畢竟裡面每個項目都是被廣泛使用的。

MySQL 裡 performance_schema 對效能的影響

最近在弄 MySQL 的 perforemance_schema，開起來後發現效能影響沒有很大，跟印象中不太一樣... 找了一下文章發現 Percona 在 2017 年年初時有針對效能測試過：「Performance Schema Benchmarks: OLTP RW」。重點在這張圖：

圖上可以看到 Default 其實對效能的影響有限，另外文章也整理出來，有哪些設定對效能影響不會太大，可以考慮平常就開著：

Using Performance Schema with the default options, Memory, Metadata Locks and Statements instrumentation doesn’t have a great impact on read-write workload performance. You might notice slowdowns with Stages instrumentation after reaching 32 actively running parallel connections. The real performance killer is Waits instrumentation. And even with it on, you will start to notice a performance drop only after 10,000 transactions per second.

Netflix 的 FrameScope，將效能資料轉成 2D 圖片

Netflix 丟出了 FlameScope，另外一種顯示效能的工具，將效能資料轉成 2D 圖片：「Netflix FlameScope」。

We’re excited to release FlameScope: a new performance visualization tool for analyzing variance, perturbations, single-threaded execution, application startup, and other time-based issues.

然後這個工具同樣是發明火焰圖的 Brendan Gregg 與他的同事 Martin Spier 的作品：

FlameScope was developed by Martin Spier and Brendan Gregg, Netflix cloud performance engineering team. Blog post by Brendan Gregg.

火焰圖 (flame graph) 就是這個：

這次推出的是這樣的圖：

其實是每秒切一次 offset 做出來的圖：

就可以很簡單的看出來哪些區塊以及 pattern 是熱點：

Percona 版本的 MySQL 對於 Meltdown/Spectre 漏洞修復造成的效能損失 (Intel 平台)

而且這還不是完全修復，只是大幅降低被攻擊的機率...

Percona 在 Ubuntu 16.04 上測試 Meltdown 與 Spectre 這兩個安全漏洞的修正對於效能的影響。在原文標題就講了結論，為了修正 Meltdown 與 Spectre 兩個安全漏洞，效能的損失很明顯：「20-30% Performance Hit from the Spectre Bug Fix on Ubuntu」。

這邊測的結果發現，在 CPU bound 時的損失大約是 20%～25% (甚至到 30%)，而 I/O bound 會輕一些，大約是 15%～20%：

We can see that in CPU-bound workloads the overhead is 20-25%, reaching up to 30% in point select queries. In IO-bound (25G buffer pool) workloads, the observed overhead is 15-20%.

在 comment 的地方 Percona 的人被問到 AMD 平台上效能會損失多少的問題，但因為他們手上目前沒有 AMD 平台的新機器所以不知道會有多少：

I do not have modern AMD servers on my hands right now

理論上 AMD 平台不需要處理 Meltdown 問題，損失應該會少一些，但沒測過也不曉得會是什麼情況... (像是 Spectre 的修正損失會不會比 Intel 還重，這之類的...)

另外補上早些時候的文章，當時 Ubuntu 上的 kernel 只有對 Meltdown 攻擊的修正，當時 Percona 的人也測了一次：「Does the Meltdown Fix Affect Performance for MySQL on Bare Metal?」，看起來對 Meltdown 攻擊的修正對效能的影響不太大，不過文裡有測試到 syscall 的效率的確如同預期掉很多。

FreeBSD 上的 ccp (AMD Crypto Co-Processor)

看到 FreeBSD 上的「[base] Revision 328150」，將 AMD 的 AMD Crypto Co-Processor。

然後實測效能頗爛 XDDD 不過本來就不是以效能為主吧... 應該是以安全性與 Trusted Platform Module 考量？

像是 4KB buffer 的效能明顯比 AES-NI 慢了一大截 (少了一個零 XDDD)：

aesni:      SHA1: ~8300 Mb/s    SHA256: ~8000 Mb/s
ccp:               ~630 Mb/s    SHA256:  ~660 Mb/s  SHA512:  ~700 Mb/s
cryptosoft:       ~1800 Mb/s    SHA256: ~1800 Mb/s  SHA512: ~2700 Mb/s

如果是 128KB buffer 時會好一些：

aesni:      SHA1:~10400 Mb/s    SHA256: ~9950 Mb/s
ccp:              ~2200 Mb/s    SHA256: ~2600 Mb/s  SHA512: ~3800 Mb/s
cryptosoft:       ~1750 Mb/s    SHA256: ~1800 Mb/s  SHA512: ~2700 Mb/s

然後 AES 也類似：

aesni:      4kB: ~11250 Mb/s    128kB: ~11250 Mb/s
ccp:               ~350 Mb/s    128kB:  ~4600 Mb/s
cryptosoft:       ~1750 Mb/s    128kB:  ~1700 Mb/s

所以是 sponsor 有認證需要的關係嗎...

Sponsored by: Dell EMC Isilon

原來 Oracle 與 Microsoft 裡的條款是這樣來的...

看到「That time Larry Ellison allegedly tried to have a professor fired for benchmarking Oracle」這篇文章的講古，想起很久前就有聽過 Microsoft 有這樣的條款 (禁止未經原廠同意公開 benchmark 結果)，原來是 Oracle 在三十幾年前創出來的？而且這種條款還有專有名詞「DeWitt Clauses」，出自當初被搞的教授 David DeWitt...

Microsoft 的條款是這樣：

You may not disclose the results of any benchmark test … without Microsoft’s prior written approval

Oracle 的則是：

You may not disclose results of any Program benchmark tests without Oracle’s prior consent

IBM 的反而在 license 裡面直接允許：

Licensee may disclose the results of any benchmark test of the Program or its subcomponents to any third party provided that Licensee (A) publicly discloses the complete methodology used in the benchmark test (for example, hardware and software setup, installation procedure and configuration files), (B) performs Licensee’s benchmark testing running the Program in its Specified Operating Environment using the latest applicable updates, patches and fixes available for the Program from IBM or third parties that provide IBM products (“Third Parties”), and © follows any and all performance tuning and “best practices” guidance available in the Program’s documentation and on IBM’s support web sites for the Program…

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.

Symfony 4 將放棄 HHVM

PHP 7.x 的效能已經趕上 HHVM (甚至在某些項目超越，參考下面的連結)，這使得後來大家為了相容性與擴充性的考量，HHVM 的社群一直沒有成長 (參考「PHP Versions Stats - 2017.1 Edition」這邊，作者從 packagist.org 上得到的數據)：

這使得 Symfony 決定在 Twitter 上蒐集意見，而後決定下一個 major version (4) 將不再支援 HHVM：「Symfony 4: End of HHVM support」。

馬上想到的是 Laravel 用了一堆 Symfony 的元件啊，之後應該會看到 Laravel 也開槍... 可以預料 HHVM 接下來會只剩下 Facebook 用，甚至過個幾年後有可能看到 Facebook 又換回 PHP (然後再打自己的 patch 上去)。

用 Go 寫的 Badger

Dgraph 在推銷自家發展出來的 Badger：「Introducing Badger: A fast key-value store written natively in Go」。

標靶是 RocksDB，號稱比 RocksDB 快好幾倍：

Based on benchmarks, Badger is at least 3.5x faster than RocksDB when doing random reads. For value sizes between 128B to 16KB, data loading is 0.86x - 14x faster compared to RocksDB, with Badger gaining significant ground as value size increases. On the flip side, Badger is currently slower for range key-value iteration, but that has a lot of room for optimization.

不過我覺得有些重要的功能在 Badger 不提供，這比起來有種橘子比蘋果的感覺... 像是 RocksDB 提供了 Transaction，而 Badger 則是直接講明他們不打算支援 Transaction：

Keep it simple, stupid. No support for transactions, versioning or snapshots -- anything that can be done outside of the store should be done outside.