pages

用 GitHub Actions 做的監控服務 Upptime

是在 Twitter 上看到這個：

Introducing the new phpBB Status Site https://t.co/V20jmQk4Px

— phpBB (@phpbb) May 8, 2022

然後翻到 Upptime 這個 open source monitoring 工具，直接是用 GitHub Actions 提供的 schedule (cron job) 每五分鐘跑一次。這邊要注意的是，如果是 public repository 的話不受限制，如果是 private repository 的話會有機會把 quota 吃完：

Billing note: Upptime uses thousands of build minutes every month (approximately 3,000 minutes in the default setting). If you use a public repository, GitHub offers unlimited free build minutes, but if you use a private repository, you'll have to pay for this time.

依照說明是用 GitHub Actions、GitHub Issues、GitHub Pages 三個功能在運作：

GitHub Actions is used as an uptime monitor

GitHub Issues are used for incident reports

GitHub Pages are used for the status website

除了用這三個功能外，另外還是會每天塞一些資料回 git history 裡面：

We also record the response time once per day and commit it to git history. This way, we can graph long-term trends in your websites' response times by going through git commit history. We generate these graphs once every day, also using schedulers.

好像可以玩看看...

GitHub 宣佈在 github.io 上抵制 FLoC

GitHub 的公告簡單明瞭，也不用你操作，直接在 github.io 上抵制 FLoC：「GitHub Pages: Permissions-Policy: interest-cohort=() Header added to all pages sites」，在「[Feature request] Set HTTP header to opt out of FLoC in GitHub Pages」這邊有些討論，另外在 Hacker News 上的討論也可以看一下：「GitHub blocks FLoC across all of GitHub Pages (github.blog)」。

不過不確定為什麼 custom domain 的就不加上去，可能微軟內部的法務團隊討論出來的結果？

All GitHub Pages sites served from the github.io domain will now have a Permissions-Policy: interest-cohort=() header set.

Pages sites using a custom domain will not be impacted.

把 HTML 資料都塞到 URL 裡的服務

如標題說的，專案叫做「URL Pages」，是一個把 HTML 的原始碼都放到 url string 裡的服務。服務本身可以在 http://jstrieb.github.io/urlpages 這邊使用。

現在網路上有很多地方可以塞 demo page (像是 GitHub 自己提供的 GitHub Pages)，這個方式需要依賴 JavaScript 提供各種轉換機制，應該會有不少 side-effect bug，看起來會有不少技術瓶頸，就當作是個實驗性質的專案來看，真的需要放 demo page 的還是可以隨便找空間放比較簡單，像是前面提到的 GitHub Pages 其實可以直接在 GitHub 的網頁上操作...

靜態網頁服務的選擇

在 Hacker News 上看到「Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains (github.com)」這篇，除了文章連結外，留言提到了不少工具...

一種是透過 GitHub Pages 的方式提供服務，或是透過 Netlify，需求真的需要動到 AWS 元件的情況其實還是考慮用傳統一點的架構 (EC2 或是 VPS) 會更有彈性。

算是提出一個雞肋後，其他人把真正有用的工具整理了出來...

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 裡面待多久...

用 GitHub + Netlify + Cloudflare 管理靜態網站...

最近 GitHub Pages 支援 HTTPS (透過 Let's Encrypt，參考「GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務」這篇)，但測了一下不是我想要的效果，就找了一下網路上的資源，結果有找到還算可以的方案...

先把網站放在 GitHub 上。(不需要設定 GitHub Pages)
然後用 Netlify 變成網站並且開啟 HTTPS。(可以選擇使用系統內提供的 Let's Encrypt，會透過 http-01 認證。如果因為 DNS 還沒生效的話也沒關係，可以之後再開。)
然後用 Cloudflare 管理 DNS 的部份 (主要是因為他的 root domain 可以設 CNAME，一般會提到的 ALIAS 就是指這個)。

這樣整個靜態服務都不用自己管理，而且有蠻多 header 可以設定，其中與 GitHub Pages 最主要的差異是 Netlify 支援 301/302 redirect。而關於 Netlify 的設定範例 (簡單的)，可以參考我在 GitHub 上的 git.tw repository。

然後 Netlify 上可以自己設定 header，當設定 HSTS 之後，SSL Labs 的跑分也可以到 A+。

整包目前看起來唯一的限制是 Netlify 的 125k requests/month (平均下來大約 4k requests/day)，不過只拿來做 redirect 應該還好...

PS：如果有人要推薦其他的組合也歡迎...

GitHub 透過 Let's Encrypt 提供自訂網域的 HTTPS 服務

以往在 GitHub 上如果要使用 HTTPS 只能使用 *.github.io 網域，現在 GitHub 宣佈透過 Let's Encrypt 的服務支援了：「Custom domains on GitHub Pages gain support for HTTPS」：

We have partnered with the certificate authority Let’s Encrypt on this project. As supporters of Let’s Encrypt’s mission to make the web more secure for everyone, we’ve officially become Silver-level sponsors of the initiative.

不過目前只支援 CNAME record (標準) 或是 ALIAS record 的方式 (非標準，也稱為 ANAME，有些 DNS provider 有支援，主要用在網域本身 (i.e. root domain) 無法使用 CNAME)。

如果是使用 A record，則是需要更新 IP 位置：

If you are using A records, you must update your site’s DNS records with new IP addresses. Please see our guide to setting up your custom domain with Pages and update any A records you might have set.

另外也提供 HTTP 轉 HTTPS 的選項：

以前 HTTPS 還得自己弄伺服器處理，現在可以直接往 GitHub 上丟了...

另外用查出來的 IP 看了一下架構，IP 是 Fastly 的，所以應該是跟 Fastly 合作，但不確定是 Fastly 自己搞定 Let's Encrypt 的憑證，或是 Fastly 提供 Port 80/443 的 TCP Proxy？

在 Google Chrome 上關閉 AMP (Accelerated Mobile Pages)

裝了 Amplifier AMP/Canonical switcher，在 Google Chrome 上可以關閉 AMP 頁面 (Accelerated Mobile Pages)。專案的 GitHub 頁面在 jpettitt/amplifier：

This extension is designed for developers working with the AMP (Accelerated Mobile Pages) standard. It detects AMP links in the page header and allows quick switching between the AMP and Canonical version of a page. Optionally AMP pages can be loaded with the AMP validation enabled (#development=1).

每一家的 AMP 連結結構都不一樣，所以就只好裝個套件快速切了...