維基基金會 (包括維基百科) 的官方服務狀態頁

看到「Announcing www.wikimediastatus.net」這個,維基基金會相關服務的官方狀態頁:「www.wikimediastatus.net」。

從頁面下面的「Powered by Atlassian Statuspage」這邊可以看出來是使用 Statuspage 這個服務。

看起來當 server error 狂噴的時候這邊應該有機會看到 (剛好前陣子好像有發生),另外 Total request volume 這個指標也透漏了目前整個維基基金會服務尖峰會有 150Kreqs/sec 的量,可以預期大多數應該都是維基百科相關的服務...

不過大多數的量應該都是從 cache server 吐出去,不知道有沒有後端 PHP loading 的數字...

MySQL (InnoDB) 的內部狀態

Percona 老大 Peter Zaitsev 在「MySQL – A Series of Bad Design Decisions」這篇裡提到了他認為 MySQL 設計上的問題,不過裡面也提到了不少有用的指令,平常可以先熟悉一下輸出,等真的有狀況的時候才會想起來可以用這些指令。

首先是最經典的 SHOW ENGINE INNODB STATUS,算是很多文件上面都會提到的指令。可以看 InnoDB 當下的情況,藉以猜測內部現在是怎麼卡住...

另外一個是 SHOW ENGINE INNODB MUTEX,就如同 Peter Zaitsev 所提到的,這個指令想辦法抓出最重要的資訊,但不要像 SHOW ENGINE INNODB STATUS 給了那麼多。

另外當然就是 INFORMATION_SCHEMA,他甚至希望 SHOW ENGINE INNODB 系列的指令應該要被整合進去,這樣才能用 SELECT 相關的指令整理... (因為 ORDER BY 以及蠻多的指令沒辦法在 SHOW ... 上面用)

用 IPFS 放 Status Page

Hacker News Daily 上看到的專案,拿 IPFS 來放 Status Page 真的超適合的,靜態為主,然後又可以避開 SPoF:「Decentralized StatusPage」。程式碼放在 GitHubpaulogr/dstatuspage,以 JavaScript 撰寫。

Hacker News 上的討論也蠻有趣的:「Show HN: A Decentralized StatusPage on IPFS | Hacker News」。

IPFS 提供的特性與 Status Page 需要的特性其實還蠻契合的,也許不是 killer application,但應該會是個 IPFS 的出發點...

而且最近 Firefox 在他們的 blog 上發表了 Firefox 59 會將一些分散式協定加進去 (不是實做,而是提供接口):「Extensions in Firefox 59」(參考 Support for Decentralization Protocols 這段),這感覺讓 IPFS 之類的協定有更寬廣的舞台...

GitHub 支援 HTTP Code 451 了...

GitHub 宣佈支援 HTTP Code 451 了:「The 451 status code is now supported」。也就是 RFC 7725 的「An HTTP Status Code to Report Legal Obstacles」。

目前會把因為 DMCA takedown notice 下架的內容以 HTTP Code 451 標出:

The GitHub API will now respond with a 451 status code for resources it has been asked to take down due to a DMCA notice.

HTTP Code 451 的點子出自「華氏 451 度」這本書,表示紙的燃點。

GitHub 提供更輕量的 Commit Reference SHA-1 API

GitHub 提供了新的 API 讓 client 可以更省網路資源,同時 GitHub 本身也可以省下 query。雖然是 Preview 期間,但已經有專案開始用了:「Commit Reference SHA-1 Preview Period」。

本來是這樣抓:

curl "https://api.github.com/repos/Homebrew/homebrew/commits/master" \
  -H "Accept: application/vnd.github.chitauri-preview+sha"

現在則可以加上 If-None-Match

curl "https://api.github.com/repos/Homebrew/homebrew/commits/master" \
  -H "Accept: application/vnd.github.chitauri-preview+sha" \
  -H "If-None-Match: \"814412cfbd631109df337e16c807207e78c0d24e\""

當本地與遠端的 SHA-1 值一樣時會收到 304,而且不會吃 rate limit quota:

If the remote and your local branch point to the same SHA-1 then this call will return a 304 Unmodified status code (and not use your rate limit).

尤其是當 commit reference 指到的 commit 特別大包時,可以省下很多資源...

HTTP Status Code 451

前陣子送出的 HTTP Status Code 451 要通過成為標準了:「Why 451?」。

Today, the IESG approved publication of "An HTTP Status Code to Report Legal Obstacles". It'll be an RFC after some work by the RFC Editor and a few more process bits, but effectively you can start using it now.

取自「華氏451度」這部講出版物言論自由的作品 (紙的燃點是華氏 451 度),在 Internet 時代,451 剛好在 HTTP Status Code 4xx 的範圍,被拿來用做「因法令限制而服法提供內容的 Status Code」。

在文件開頭說明了這個代碼的用途:

This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.

GitHub 支援 Protected Branches 了...

GitHub 宣布支援 Protected Branches 了:「Protected branches and required status checks」,其他的競爭對手都有的功能:

Over the next few weeks we’ll be rolling out a new feature called Protected Branches which gives repository administrators the ability to disable force pushes to specific branches.

另外一起引入的是強制性的檢查:

算是補功能... 組織變大的時候必須透過系統強制介入的功能。

MySQL InnoDB 遇到 Deadlock 時的判讀

Percona 的「How to deal with MySQL deadlocks」這篇文章裡面提到了 MySQL InnoDB Deadlock 的判讀與處理。

在支援 transaction 的 engine 裡 deadlock 是不可避免的常態。

在 MySQL 5.5 以及之前的版本,可以透過 Percona 的 pt-deadlock-logger 這隻 script,每固定幾秒鐘就跑一次 SHOW ENGINE INNODB STATUS 記錄下來。在 MySQL 5.6 之後,可以直接使用 innodb_print_all_deadlocks 這個參數,遇到 deadlock 時就寫到 error log 裡。

有了 log 後,接下來就可以判讀 deadlock 的情況,得知是什麼樣的情況造成 deadlock。

文章最後面則是對減少 deadlock 的方法給了一些建議,都是比較一般性。一般還是要靠 bussiness logic 的分析來切割降低 deadlock 的情況。

不過這篇文章需要一些背景知識,像是 InnoDB Lock Modes 與維基百科上的「Multiple granularity locking」,對解讀會有更多幫助。

OCSP stapling

OCSP (Online Certificate Status Protocol) 是用來檢查 SSL certificate 是否被撤銷的方法。OCSP server 接受 HTTP POST 後,回答 client 這個 SSL certificate 是否仍然有效。

對於 client 來說,這主要有兩個問題:

  • client 需要多花時間連到 OCSP server 確認。
  • 隱私問題:OCSP server 會知道「這個使用者試著連到使用這個 SSL certificate」的資訊。

而對於 OCSP server 來說,這個方法的 scalability 很差,熱門的站台會產生大量的流量打進 OCSP server。

OCSP stapling 則是解決這個問題的方法。藉由 server 向 OCSP server 要一次 OCSP response 後,直接傳回 OCSP response 給 client (通常是 browser) 避開了上面的問題。這個方法也逐漸在普及了:(取自英文版維基百科文章內的說明)

OCSP stapling has not seen broad deployment to date, however this is changing. The OpenSSL project included support in their 0.9.8g release with the assistance of a grant from the Mozilla Foundation.

Apache HTTP Server supports OCSP stapling since version 2.3.3, the nginx web server since version 1.3.7, and LiteSpeed Web Server since version 4.2.4. and Microsoft's IIS since Windows Server 2008

On the browser side, OCSP stapling was implemented in Firefox 26 and in Internet Explorer since Windows Vista.

所以已經有不少 client 與 server 都支援了...