Tag: benchmark

在一連串的安全更新後，AMD 的 CPU 比 Intel 快了...

在「Intel Performance Hit 5x Harder Than AMD After Spectre, Meltdown Patches」這邊看到的測試：

把現有的安全性更新都開啟後，Intel CPU 的效能掉了 20% 左右 (在 Intel 上需要把 HT 關掉)：

While the impacts vary tremendously from virtually nothing too significant on an application-by-application level, the collective whack is ~15-16 percent on all Intel CPUs without Hyper-Threading disabled. Disabling increases the overall performance impact to 20 percent (for the 7980XE), 24.8 percent (8700K) and 20.5 percent (6800K).

The AMD CPUs are not tested with HT disabled, because disabling SMT isn’t a required fix for the situation on AMD chips, but the cumulative impact of the decline is much smaller. AMD loses ~3 percent with all fixes enabled

可以注意到兩家目前桌機的頂規在上了安全性更新後，AMD 的 2990WX 比 Intel 的 7980XE 快了一些些... 當初擠牙膏擠出來的都吐回去了，不知道之後出的 security issue 還需要再吐多少回去。

Percona 對於 PostgreSQL 使用 HugePages 的評論

開頭我先說一下我的想法，我對於 Percona 的 Ibrar Ahmed 的文章保持著懷疑的態度，因為他先前在「Benchmark PostgreSQL With Linux HugePages」這篇做的 benchmark 就有奇怪的結果，但卻給不出合理的原因，甚至連 Percona 自家的 CEO 公開在 comment 問之後也沒有看到文章提出合理的解釋：

Hi,

A lot of interesting results here…

1) PgBench access distribution is very interesting. With database size growing by 20% from 80G to 96G we see performance drop of Several times which is very counter-intuitive

2) There is no difference between 2MB and 4K but huge difference between 1G and 2M even though I would expect at least some TLB miss reduction in the first transitioning. I would understand it in case transparent huge pages are Enabled… but not disabled

3) For 96GB why would throughput grow with number of clients for 1G but fall for 2M and 4KB.

這次看到「Settling the Myth of Transparent HugePages for Databases」這篇，也是在討論 Linux 的 HugePages 對 PostgreSQL 帶來的影響，同樣馬上又看到奇怪的東西...

首先是標示與圖片不合：

Figure 1.1 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload(48GB) < shared_buffer (64GB)

Figure 1.2 PostgreSQL’ s Benchmark, 10 minutes execution time where database workload (48GB) > shared_buffer (64GB)

不過這邊可以推測 Figure 1.2 應該是 112GB (因為對應的圖片上面標的是 112GB)，當做是標錯就好。

但這樣又跑出一個奇怪的結果，48GB 的資料量比較小，TPS 大約是 35K/33K/41K，但 112GB 資料量比較大，卻可以達到 39K/43K/41K~42K，反而比較快？我暫時想不到什麼理由...

整體的測試有 pgbench 與 sysbench (這邊也打錯成 sysbecnch，先不管)，其中 pgbench 跑了 10 mins 與 60 mins 的版本，但是 sysbench 只跑了 10 mins 的版本？這是什麼原因...

另外還是有些情況是打開 HugePages 比較快的 (sysbench 的 64 clients)，如果以直覺來說的話，我反而還是會打開 HugePages (yeah 純粹是直覺)，我現在比較想知道他會在 Percona 裡面待多久...

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.