Tag: blog

WordPress 誕生 20 年

Matt Mullenweg 寫了一篇文章簡單提到 WordPress 誕生 20 年：「WP20 & Audrey Scholars」。

雖然 Matt Mullenweg 在文章裡都沒提到，但 WordPress 的興起其實跟當年 2004 年最大的 blog 軟體 Movable Type 自己出的包有很大的關係：

With the release of version 3.0 in 2004, there were marked changes in Movable Type's licensing, most notably placing greater restrictions on its use without paying a licensing fee. This sparked criticism from some users of the software, with some moving to the then-new open-source blogging tool WordPress. With the release of Movable Type 3.2, the ability to create an unlimited number of weblogs at all licensing levels was restored. In Movable Type 3.3, the product once again became completely free for personal users.

當年 hlb 在社團主機上用 Movable Type 架了服務讓大家寫，結果後來發生了 license 問題，大家就都順勢跑到 WordPress 上了；而等到 Movable Type 再次想放寬 license 的時候已經來不及了，大家都已經搬完了。

翻了一下最舊的文章 (在另外一個 WordPress 上) 是在 2004 年十月的時候寫的，就有提到當時從 Movable Type 換到 WordPress 的考量：「開場：為什麼用 WordPress」。

備份 Xuite Blog 的公開文章

中華的 Xuite 前陣子宣佈了服務中止的公告：「Xuite隨意窩平台服務終止公告」(這邊就先拉 Internet Archive 的連結了，看起來之後會消失...)。

Blog 的部份，除了作者本身可以拉資料下來放到其他平台以外，外人也可以把這些歷史遺跡保留下來，像是丟到 Internet Archive 的 Wayback Machine 上面。

所以用 Perl 寫了一隻 script，把 url 掃出來後，後續就可以用其他工具 submit 到 Wayback Machine 上面：「xuite-urldump」。

當年有不少 ACG 相關的 blog 在上面，先來備份起來...

WordPress 打算要支援 SQLite 作為後端資料庫

目前 WordPress 只有支援 MySQL，而昨天在 Hacker News 上看到 WordPress 有打算要支援 SQLite 作為後端資料庫的消息：「WordPress testing official SQLite Support (github.com/wordpress)」，原文在 GitHub 上：「Implement new experimental SQLite integration module」。

理論上對使用者會更方便，但對 extension 開發者會麻煩一些 (或是直接標不支援？)，尤其是用到 MySQL 特有的語法就要注意了。

實質上 PHP + MySQL hosting 其實蠻常見的，這個作法有多少幫助就不知道了。

但突然想到，如果做一個 read-only 版本的 WordPress 站台，然後把 SQLite 的讀取部份改用 sql.js 之類的計畫，再把一堆 server side rendering 的部份變成 client side rendering，好像有機會可以整包直接上 GitHub Pages 之類的服務？雖然這樣有點拖褲子放屁...

又有 Blog Search Engine 了：Blog Surf

在「Show HN: Search Engine for Blogs (blogsurf.io)」這邊看到又有 blog search engine 了，叫做 Blog Surf。

比較有趣的應該是留言裡面看到這個，已經掛掉的先人出來說，以前這個使用族群都是在打手槍的族群 XDDD

mgarfias 12 hours ago

We, sphere.com, did this starting in 2006. After a year or so, we realized the only people using the service were looking to stroke their egos.

Ice rocket, and something else (I can’t remember the name) tried it at the same time and failed.

We pivoted, which ended up leading to some unspeakable horrors.

At any rate, good luck, hope it works better for you.

回到 Blog Surf 來看，在 About 頁上提到了 MarketRank，基本上就是服務作者提出來的演算法：

Points are calculated using Market Rank. They are a measure of the popularity of a post across online communities. Blog points are simply the sum of a blog’s post points.

不是太看好但就觀察看看...

把 Blog 丟到 CloudFront 上

先前在「AWS 流量相關的 Free Tier 增加不少...」這邊有提到一般性的流量從 1GB/month per region 升到 100GB/month，另外 CloudFront 則是大幅增加，從 50GB/month (只有註冊完的前 12 個月) 提升到 1TB/month (不限制 12 個月)，另外 CloudFront 到 EC2 中間的流量是不計費的。

剛剛花了點功夫把 blog 從 Cloudflare 搬到 CloudFront 上，另外先對預設的 /* 調整成 no cache，然後針對 /wp-content/* 另外加上 cache 處理，跑一陣子看看有沒有問題再說...

目前比較明顯的改善就是 latency，從 HiNet 連到免費版的 Cloudflare 會導去美國，用 CloudFront 的話就會是台灣了：

另外一方面，這樣國際頻寬的部份就會走進 AWS 的骨幹，比起透過 HiNet 自己連到美國的 PoP 上，理論上應該是會快一些...

把 blog 從 t4g.small 降到 t4g.micro

我在「把 blog 搬到 t4g.small 上」這邊有提到把這個 blog 搬到 Amazon EC2 的 t4g.small 上 (2GB RAM + 20% CPU credit)，跑了一陣子把 CPU usage 拉出來看：

當初估大約要 20% 的 CPU credit，結果發現 CPU credit 大概用 5% 就夠了。另外記憶體的部份大約要給 1GB，這個量可以看出來一些沒在用的 process 會被丟到 swap：

              total        used        free      shared  buff/cache   available
Mem:          952Mi       380Mi        79Mi       110Mi       492Mi       368Mi
Swap:         511Mi       152Mi       359Mi

把條件綜合起來計算，就往下降一階變成 t4g.micro 了 (1GB RAM + 10% CPU credit)。

另外新機種比較不用擔心淘汰速度，就看了一下 Reserved Instances 的價錢，一年 USD$44，三年 USD$84，看起來只要有用兩年就算是 OK，直接買三年解決掉...

把 blog 搬到 t4g.small 上

算了一下成本還可以接受 (機器 + 空間 + 流量)，就把 blog 搬到 AWS 的 t4g.small (ARM) 上，理論上頁面的速度應該會快不少，過幾天等穩定性沒問題後就來買 RI...

從 x86-64 轉到 ARM 上面，主要是 Percona Server 目前沒有提供 ARM binary 的 apt repository，所以就改用 MariaDB 了。

其他的倒是都差不多，目前的 Ubuntu + nginx + PHP 沒什麼問題，跑一陣子看看...

這幾天 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_files 與 FastCGI 相關的設定：

    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

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 也快出了...