PHP 8.0 快要出了

看到 WordPress 的這篇「WordPress and PHP 8.0」,看起來 PHP 8.0 快要出了:

PHP 8.0 is in the final stages of its release cycle. As of the publish date of this post, version 8.0 RC5 has been released, and the final release of PHP 8.0.0 is scheduled for November 26, 2020.

官網上已經有一些資料可以看了,不過記得畢竟還沒 release,裡面的資訊還有可能會修正:「Migrating from PHP 7.4.x to PHP 8.0.x」,最重要的應該還是「Backward Incompatible Changes」這邊,可以看到這次畢竟是主版號升級,精彩的不相容性應該會搞爆不少應用程式,像是開頭就提到的,對數字與文字之間的 == 行為改變:

比較好的作法是自己先轉型再用 === 比較,這個概念在各家程式語言都類似,loose comparison 只是方便而已...

這幾天 blog 被掃,用 nginx 的 limit_req_zone 擋...

Update:這個方法問題好像還是不少,目前先拿掉了...

這幾天 blog 被掃中單一頁面負載會比較重的頁面,結果 CPU loading 變超高,從後台可以看到常常滿載:

看了一下是都是從 Azure 上面打過來的,有好幾組都在打,IP address 每隔一段時間就會變,所以單純用 firewall 擋 IP address 的方法看起來沒用...

印象中 nginx 本身可以 rate limit,搜了一下文件可以翻到應該就是「Module ngx_http_limit_req_module」這個,就設起來暫時用這個方式擋著,大概是這樣:

limit_conn_status 429;
limit_req_status 429;
limit_req_zone $binary_remote_addr zone=myzone:10m rate=10r/m;

其中預設是傳回 5xx 系列的 service unavailable,但這邊用 429 應該更正確,從維基百科的「List of HTTP status codes」這邊可以看到不錯的說明:

429 Too Many Requests (RFC 6585)
The user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.

然後 virtual host 的設定檔內把某個 path 放進這個 zone 保護起來,目前比較困擾的是需要 copy & paste try_filesFastCGI 相關的設定:

    location /path/subpath {
        limit_req zone=myzone;
        try_files $uri $uri/ /index.php?$args;

        include fastcgi.conf;
        fastcgi_intercept_errors on;
        fastcgi_pass php74;
    }

這樣一來就可以自動擋下這些狂抽猛送的 bot,至少在現階段應該還是有用的...

如果之後有遇到其他手法的話,再見招拆招看看要怎麼再加強 :o

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

先前在「Amazon EC2 的 M6g 系列正式推出了」這邊提到了 AWSAmazon 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...

AWS 官方推出 WordPress 整合套件

AWS 自己推出了跟 WordPress 的整合套件:「Accelerating WordPress with CloudFront using the AWS for WordPress Plugin」、「AWS for WordPress plugin now available and with new Amazon CloudFront workflow」。

這次的套件主要是將 Amazon CloudFront 整合進 WordPress:

Amazon Web Services announces the general availability of the AWS for WordPress plugin. Previously known as the Amazon Polly and Amazon AI plugin, the new AWS for WordPress plugin now provides a workflow to configure an Amazon CloudFront distribution that is highly optimized for WordPress websites.

如果想要都控制在自己手上,AWS 算是提供了一個官方的方案,也應該有一定的支援。不過大多數人還是會拿 Cloudflare 的免費方案吧...

換到 PHP 7.3

上次是 2018 年五月把 PHP 換到 7.2 (參考「把 Blog 換成 PHP 7.2」),這次是在整理機器時發現 blog 這台機器還在跑 7.2,就更新一下系統把上面的站台都換到 7.3。

蠻多人都測過效能了 (像是「The Definitive PHP 5.6, 7.0, 7.1, 7.2 & 7.3 Benchmarks (2019)」),目前看到的資料都會快一些,應該是沒有太大問題,之後可以考慮再把 OPcache 的可用空間大小再降一些 (預設是 128 MB,但用 opcache-status 看起來只用了 65 MB 左右),把記憶體空間讓給其他程式用...

不過 7.4 也快出了...

Automattic (WordPress.com 的公司) 買下 Tumblr

Verizon 一直在把 Yahoo! 手上比較有價值的資產賣掉,總算是輪到 Tumblr 了,這次是賣給了 Automattic,也就是 WordPress.com 營運的公司。

Verizon 已經發新聞稿了:「Verizon Media announces sale of Tumblr to Automattic」,Tumblr 的 staff blog 上也發表了:「Hello Tumblr ? Today, Tumblr’s owner, Verizon...」,但 Automattic 這邊還沒看到:「Features, news, and more: See what’s been going on in Automattic’s world.」。

金額不確定多少,但感覺應該算是好事?不知道之前的 porn content 會不會回流...

補上 WordPress 編輯器的 accesskey

WordPress 編輯文章時我還是習慣用傳統編輯界面自己修改主要的 html tag,像是這樣:

上面那些按鈕在很久以前的版本透過 accesskey 用鍵盤快速輸入各種連結與效果,但後來就被拿掉了... 不過可以在「Adding WordPress Custom QuickTags」這邊看到一些文章有提到過。

研究了一下 WordPress 的 minimal plugin 有哪些東西,看起來也不難寫,就花了些時間用 js 操作,這樣編輯起來方便多了... 程式包起來放到 gslin/wp-editor-accesskey 上,有需要的也可以拿去用,不過我猜現在還這樣寫文章的人不多了...

WordPress 5.0 的編輯界面大改...

WordPress 升級到 5.0 後發現完全不會用新的編輯器了 (我是自己編 html 習慣了),去官方的 forum 上看一下有沒有其他人抱怨 (以及解法),看到「READ THIS FIRST WordPress 5.0 Master List」這篇公告。

公告裡提到可以裝「Classic Editor」這個 plugin 把舊的 editor 弄回來寫文章,而且這個 plugin 至少維護到 2022 年:

Classic Editor is an official WordPress plugin, and will be maintained until at least 2022.

本來打算要 downgrade 回舊版... 目前看起來還可以撐一段時間。

WordPress 在 Internet 上的情況

WordPress 在 Internet 有很大的佔有率,在「Usage statistics and market share of WordPress for websites」這邊有一直更新的資料,現在是:

WordPress is used by 59.9% of all the websites whose content management system we know. This is 29.1% of all websites.

這數字可以參考看看。而在「State of the WordPress ecosystem」這邊就看到有人在分析 WordPress 在整個 Internet 上的情況。可以看到裡面有蠻多都是透過 BigQuery 分析出來的...

在分析整個頁面的平均下載量時,可以看到 WordPress 的頁面比較肥:

We get 1590 KB for wordpress=false and 1897 KB for wordpress=true.

但是在 WordPress 上未最佳化的圖片比較少,原文裡猜測是歸功於 plugin 的關係:

@amedina I wonder if this has to do with the availability of tools/plugins in the WordPress ecosystem that optimize images effortlessly, as opposed to other web development pipelines that require manual image optimization or installation of specialized tools.

所以就跑去分析了 WordPress 上使用了哪些 plugin,不過這是看 web request 以及 path 得到的,如果 plugin 是純粹在內部執行的話就看不到了:

整個分析還蠻有趣的,而且還在進行...