optimizer

PHP 在 Amazon EC2 的 m5 (Intel) 與 m6g (ARM) 的效能差異

先前在「Amazon EC2 的 M6g 系列正式推出了」這邊提到了 AWS 在 Amazon EC2 上推出了以 ARM 為架構的 m6g 系列機器，剛剛看到有人拿 PHP 上的應用丟出測試的差異了：「Improving performance of PHP for Arm64 and impact on Amazon EC2 M6g instances」。

最先要注意的應該是這張：

在 PHP 7.3 的時候 Intel 平台的 m5 跑比較快，但到了 PHP 7.4 就變成 ARM 的 m6g 跑比較快了，不過這兩個版本的差異都不算太大，而到了還在開發的 PHP 8 則是出現了比較大的差距。

作者有提到主要的原因是在 PHP 7.4 之前 ARM 上不會啟用 Zend optimizer，而這個功能對效能的影響差很多，在 PHP 7.4 打開後就反轉了：

Zend optimizer is a component of the PHP runtime system that improves performance by up to 30% on a range of Zend micro-benchmarks. Before PHP 7.4 the Zend optimizer was not enabled for Arm.

而 PHP 8 的差距拉大，則是因為 PHP 有更多針對 ARM 平台的改善，像是這邊提到的 NEON 指令集：

PHP-8 plans to release in 2021 with more improvements for Arm64: an improved toupper/tolower function brings performance up by 16.5x. https://github.com/php/php-src/pull/4439

除此之外，AWS 也對 PCRE2 提供了使用 NEON 指令集的加速的 patch：

AWS has contributed changes to PCRE2 release 10.34. PCRE2 version 10.34 is used in PHP-8 to match regular expressions. PCRE2 accounted for about 8% of execution time in WordPress benchmark. The change contributed by AWS to PCRE2 vectorizes first character match and matching pairs of characters with NEON instructions: performance improves by up to 8x on M6g.

這樣可以看到 ARM 平常應該會愈來愈成熟，而更重要的是 m6g 系列機器比 m5 便宜不少：以作者測試的 {m5,m6g}.4xlarge 來看，分別是 USD$0.768/hr 與 USD$0.616/hr，大約是 20% 的差距，加上效能上的差距，C/P 值看起來是真的有到官方宣稱的 40%，這點在其他 Plurk 也測出了類似的結果：

未來除非是 binary-only 的東西，不然應該會朝著往 ARM 上面測過，再決定要怎麼選 instance type...

MySQL 8.0 的 performance_schema 加上 index 了...

MySQL 8.0 是 MySQL 5.7 的後續版本，中間的 6.0 與 7.0 都有一些故事，就被跳過去了，跟 PHP 的情況有點像。

在 8.0 版將會把 performance_schamea 加上 index，讓查詢的速度變快：「MySQL 8.0: Performance Schema, now with indexes!」：

In MySQL 8.0, performance_schema tables are now indexed to speed up data retrieval.

A total of 115 indexes have been added in the performance schema in MySQL 8.0.0, to support better data access patterns in general.

有用過 performance_schema 的人都會有種「這好慢啊」的感覺，總算要改善了... 而且這幾乎是沒什麼成本的改善：

Question: How much overhead was just added by this new feature?
Answer: Absolutely zero

並不是用 index 加快速度，而是加了一些資訊，修正 optimizer 的行為：

It does — not — maintain a physical index internally, be it on file or memory.
It does, however, — pretend — to the optimizer that it has indexes, so that the optimizer is coerced into using the most efficient access pattern.

在有些情況下可以看到會快非常的多：

The performance improvements from indexes can be very easily seen in many of the sys schema queries. With 1000 idle threads, the query SELECT * FROM sys.session drops from 34.70 seconds down to 1.01 seconds (a 30x improvement!):

不知道 Percona 會不會 backport 回來，這看起來對於爆炸中的 server 找問題會很有幫助，可以在短時間翻出是哪個部份爆炸...

MySQL 5.7 的 Rewrite Query Plugin

在「What to do with optimizer hints after an upgrade?」這邊介紹了 MySQL 5.7 引入的 Rewrite Query Plugin，看起來有很多可以拿來變化的？

作者提到的用法是當 minor version 升級後 (譬如 5.6 升到 5.7)，由於 optimizer 愈來愈聰明，hint 應該都要重新確認是否還需要指定 (像是 USING INDEX)，避免效能反而變差。

但這個前提是你能夠改到程式碼，如果你改不到程式碼就只能祈禱效能不會變差。

而 MySQL 5.7 提供的 Rewrite Query Plugin 則可以改寫 SQL query，像是 Oracle 官方文件裡給的範例：

mysql> SELECT * FROM query_rewrite.rewrite_rules\G
*************************** 1. row ***************************
                id: 1
           pattern: SELECT ?
  pattern_database: NULL
       replacement: SELECT ? + 1
           enabled: YES
           message: NULL
    pattern_digest: 46b876e64cd5c41009d91c754921f1d4
normalized_pattern: select ?

就會把 SELECT 1 變成 SELECT 1 + 1。實際測試會發現檢查的很嚴格，用 PI() 不會變：

mysql> SELECT PI();
+----------+
| PI()     |
+----------+
| 3.141593 |
+----------+
1 row in set (0.01 sec)

mysql> SELECT 10;
+--------+
| 10 + 1 |
+--------+
|     11 |
+--------+
1 row in set, 1 warning (0.00 sec)

目前好像只想的到 hint 可以這樣做，反正還一堆都跑 5.6 (這兩天 Percona 才出 5.7 的 GA)，可以邊規劃升級，邊想看看有什麼情境可以用的...