改善 Wikipedia 的 JavaScript,減少 300ms 的 blocking time

Hacker News 首頁上看到「300ms Faster: Reducing Wikipedia's Total Blocking Time」這篇,作者 Nicholas RayWikimedia Foundation 的工程師,雖然是貼在自己的 blog 上,但算是半官方性質了... 文章裡面提到了兩個改善都是跟前端 JavaScript 有關的。

作者是透過瀏覽器端的 profiling 產生火焰圖,判讀裡面哪塊是大塊的問題,然後看看有沒有機會改善。

先看最後的成果,可以看到第一個 fix 讓 blocking time 少了 200ms 左右,第二個 fix 則是少了 80ms 左右:

第一個改善是從火焰圖發現 l._enable 吃掉很多 blocking time:

作者發現是因為 find() 找出所有的連結後 (a 元素),跑去每一個連結上面綁定事件造成的效能問題:

The .on("click") call attached a click event listener to nearly every link in the content so that the corresponding section would open if the clicked link contained a hash fragment. For short articles with few links, the performance impact was negligible. But long articles like ”United States” included over 4,000 links, leading to over 200ms of execution time on low-end devices.

但這其實是 redundant code,在其他地方已經有處理了,所以解法就比較簡單,拔掉後直接少了 200ms:

Worse yet, this behavior was unnecessary. The downstream code that listened to the hashchange event already called the same method that the click event listener called. Unless the window’s location already pointed at the link’s destination, clicking a link called the checkHash method twice — once for the link click event handler and once more for the hashchange handler.

第二個改善是 initMediaViewer 吃掉的 blocking time,從 code 也可以看到問題也類似,跑一個 loop 把事件掛到所有符合條件的元素上面:

這邊的解法是 event delegation,把事件掛到上層的元素,就只需要掛一個,然後多加上檢查事件觸發的起點是不是符合條件就可以了,這樣可以大幅降低「掛」事件的成本。

這點算是常用技巧,像是 table 裡面有事件要掛到很多個 td 的時候,會改成把一個事件掛到 table 上面,另外加上判斷條件。

算是蠻標準的 profiling 過程,直接拉出真實數據來看,然後調有重大影響的部分。

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

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

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

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

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

維基基金會對中國大陸維基人用戶組的行動 (WMCUG)

在『維基媒體基金會出手清除多名「中國大陸維基人用戶組」成員。包括封禁其在全球所有維基媒體基金會項目的帳號,或是拔除在中文維基百科的管理員權限。』這邊看到的消息,看起來目前都還在進行中,所以這幾天還可以繼續等看看消息。

中文版維基百科的管理群裡面被中國政府以及共青團伸手進來的事情是眾所皆知,只是先前維基基金會一直都是抱持沒有確切證據不處理的態度。

這次官方的正式聲明是由 Maggie Dennis 署名 (法務部門 VP),可以參考「Office actions/September 2021 statement」(英文版) 與「基金會行動/2021年9月聲明」(中文翻譯版本)。

相關的拔權記錄可以在「Special:Log/WMFOffice」這邊看到,這邊的時間應該是 UTC,可以看到還有陸陸續續在拔。另外在「Wikipedia:2021年基金會針對中文維基百科的行動」這邊也有一些記錄。

看到連 Outlookxp 都被拔了,總算是出手了啊...

另外補充一下在 mailing list 上看到的資料,原始的 Twitter 已經刪除,但 Internet Archive 上面還有備份:

https://web.archive.org/web/20210914024812/https://twitter.com/Philip_Tzou/status/1437543054043275265

Wikimedia 弄了自己的 Mattermost

Wikimedia (維基百科後面的基金會) 又多了一個溝通工具:「Introducing Wikimedia Chat!」。

最傳統的方式是在 wiki 的 Talk 頁上溝通 (現在看起來還是有些正式的投票討論需要走這個方式),但那個界面用起來真的頗痛苦... 一般的社群討論還是會在其他工具上進行。

先前有晃進去看過的平台應該是 IRC 與 Telegram 群組,不過後來因為量太大就閃出來了,另外這邊有提到 SlackDiscordFacebook

You can now see Wikimedia-related discussion groups in Slack, Discord, Telegram, Facebook, and many more.

這些平台都還是放在外部,就會有很多隱私上的考量:

Besides being scattered and inaccessible to people who don’t have accounts in those platforms (for privacy reasons for example), these platforms use proprietary and closed-source software, are outside Wikimedia infrastructure and some harvest our personal data for profit.

freenode 上面的 IRC 算是相對起來比較開放,但還是少了不少功能,所以就自己架了 Mattermost 出來:

IRC on freenode.net is a good alternative but it lacks basic functionalities of a modern chat platform. So we created Wikimedia Chat, a Mattermost instance hosted in Wikimedia Cloud.

比較特別的是超過 90 天的記錄會被砍掉?不太懂這邊的邏輯...

As a Wikimedia Cloud project, all of discussions, private and public are covered by Code of conduct in technical spaces and due to Wikimedia Cloud privacy policy all discussions older than ninety days will be deleted.

在 Unix 環境裡各種奇怪名稱的原因說明

Hacker News Daily 上看到的,DebianWiki 上有一頁整理了很多「比較特別的」軟體或是指令的名稱由來:「WhyTheName」。

像是 Git

git
(distributed VCS) semi-arbitrary short word

不過這邊不像維基百科會要求「可供查證」,裡面大多都沒有引用來源,真的要引用前最好還是去其他地方確認過...

Blockchain 的使用時機

這兩則可以一起看,首先是 Jimmy Wales 對於提議用 blockchain 記錄維基百科的回應:

另外一個是 xkcd 最近的酸圖:

腦袋裡又瞬間冒出「詐騙集團」這個詞彙 XDDD

維基百科的 Vital articles

Hacker News Daily 這邊看到,英文版維基百科有一套列表,整理出「重要」的條目:「Wikipedia:Vital articles」。

目前的列表有五個層級,從 Level 1 到 Level 5,後面的 Level 包含了前面 Level 的文章:

  • Level 1 只有 10 篇。
  • Level 2 有 100 篇 (包含 Level 1 的 10 篇,以下類推)。
  • Level 3 有 1000 篇。
  • Level 4 有 10000 篇。
  • Level 5 有 50000 篇。

看到的第一個問題就是這些列表怎麼產生的,這點在 Wikipedia talk:Vital articles/Frequently Asked Questions 裡面有提到列表的歷史:這是 2004 年由 David Gerard 發起,之後擴大到社群並且分不同等級。而這也說明了這些列表示人工選擇的,而不是透過演算法推薦的:

The English Wikipedia Vital Articles list was originally created in August 2004 by David Gerard as an adaptation of the metawiki List of articles every Wikipedia should have. Since then, the Vital Articles list has undergone numerous revisions by multiple editors, and has expanded to include 5 different levels of vitalness.

然後選擇的標準是「要了解這個領域不可或缺的條目」:

A vital article is one considered essential to the subjects listed. For example, it would be difficult to discuss Science without the scientific method, History without World War II, Language without Grammar, Earth science without Geology, or Civics without Democracy. Individuals within the People section represent the pinnacles of their field, such as Albert Einstein in "Inventors and scientists" or William Shakespeare in "Authors". In sections such as those pertaining to People, History or Geography, weight is given to some articles to produce a more diverse, global list.

這些列表其中一種用法是「想要了解某個領域」,但剛剛翻了一下 Level 1 與 Level 2 可以發現似乎太少,看起來 Level 3 的資料算是個還不錯的起點...

PostgreSQL 的 Don't Do This

Hacker News Daily 上看到的資料,整理了 PostgreSQL 上不要使用的功能:「Don't Do This」,而且是放在官方網域 wiki.postgresql.org 上。

裡面這些想法不知道出處是哪邊... 有不少功能算是 PostgreSQL 特有的功能 (以 open source RDBMS 這個領域來看),而且大概也還想的到用的場景,你卻在上面叫大家不要用,再寫的時候大概是吸了一批很純的,已經不知道要從哪邊開始吐槽...

要看的話連同 Hacker News 上的留言一起看會比較有前因後果:「https://news.ycombinator.com/item?id=19817531」。