追 MediaWiki 頁面很慢的問題

我自己有個 wiki 拿來堆一些資料,前陣子覺得 Live 這頁很慢,實際測試發現要跑五秒多,想說到底是什麼鬼...

先從 MediaWiki 的各種 optimization 設定開始看,像是 Manual:Cache 這邊提到的東西,一路看下來看起來都已經設好最佳化了。

只好拿 profiling 工具來翻,在 PHP 上面用的是 Xdebug,裝了以後希望是特殊的情況才跑 profiling,所以參考了「Profiling」這邊的說明,在 php.ini 裡面這樣設定:

xdebug.mode=profile
xdebug.start_with_request=trigger
xdebug.trigger_value=StartProfileForMe

接著依照說明,你要找個地方把這個值傳進去:

Xdebug's profiler will only start when either the environment variable XDEBUG_TRIGGER is set to StartProfileForMe, the GET or POST variable XDEBUG_TRIGGER is set to StartProfileForMe, or when the cookie XDEBUG_TRIGGER has the value StartProfileForMe.

我是在網址列上直接用 ?XDEBUG_TRIGGER=StartProfileForMe 觸發,預設值會把 profiling 結果丟到 /tmp 下面,接下來就是把 callgrind 檔案視覺化了。

首先是把 xdebug 的 callgrind 格式輸出檔案轉成 DOT 格式,這邊參考「Interpreting callgrind data」的說明,先裝 gprof2dot,這個軟體在 PyPI 上有,所以可以用 pipx 裝,接著把 callgrind 轉完後再轉成 PNG 檔案。

我把圖放到最後面 (點開可以看大圖),第一張是 Live 這頁的 profiling,第二張是 Hosting 這頁的。

我注意到在 Live 這頁 php::mysqli 這邊被呼叫了幾千次,這邊就算是本地端的資料庫,幾千次的 latency 累積起來還是很驚人,畢竟是跨 process 之間的溝通,而且已知是 ping-pong 要等待的情況。

接著去翻是什麼造成的,看起來跟 selectRow 有關,但線索到這邊就斷掉了,上面的 User->load 看起來並沒有 loop 導致大量呼叫 selectRow

但至少有個方向,從網路上沒什麼討論看起來,應該不會是本體的效能問題,而是 extension 造成的,從這個角度開始追與帳號 & 權限有關的 extension,第一發懷疑是 Extension:AccessControl 造成的,結果果然沒錯... 拔掉後頁面的速度就從 5.1 秒左右降到 1.5 秒左右了。

沒有實際追程式碼,但猜測是 wiki 裡面用的 Template 造成 AccessControl 都會去檢查權限,加上這邊沒有上 cache,造成頁面上 Template 一多效能很差...

最後,這是 Live 頁的 profiling graph:

這是 Hosting 頁的 profiling graph:

NVIDIA 正式推出開源版本的 Linux driver 了

五月的時候有提過 NVIDIA 有計畫要使用 open-source license 的 Linux driver:「Nvidia 在 Linux 上安裝核心驅動程式時將建議使用開源版本」,現在則是正式公告了:「NVIDIA Transitions Fully Towards Open-Source GPU Kernel Modules」。

支援的 GPU 分成三塊,第一塊是只有 open-source 版本有支援,目前已經推出的產品應該是只有 GH200 是這個架構:

For cutting-edge platforms such as NVIDIA Grace Hopper or NVIDIA Blackwell, you must use the open-source GPU kernel modules. The proprietary drivers are unsupported on these platforms.

然後是 Turing 後的架構,以桌機顯卡來說的話是 2016 年出的 20 系列架構 (值得提一下的是,16 系列雖然看起來數字比較小,但是是 2019 年出的 Turing 架構,所以也支援):

For newer GPUs from the Turing, Ampere, Ada Lovelace, or Hopper architectures, NVIDIA recommends switching to the open-source GPU kernel modules.

舊的系列則是不支援,以桌機來說就是 10 系列以及更舊的卡:

For older GPUs from the Maxwell, Pascal, or Volta architectures, the open-source GPU kernel modules are not compatible with your platform. Continue to use the NVIDIA proprietary driver.

再等一兩個版本再來換過去...

話說找資料發現維基百科上面用 Nvidia,但我找資料發現官方名稱是用 NVIDIA,翻了討論頁發現 2010 年就有人幹剿過了 (在 Naming Conventions 這段),看起來是不會改?

Ship of Theseus 條目的趣事

Hacker News Daily 上看到「0% of the phrases of the original Wikipedia "Ship of Theseus" article remain (twitter.com/depthsofwiki)」這篇,引用的是這則 tweet:

一開始掃過「Ship of Theseus」這個條目還沒有感覺,想偷懶發現有中文版的條目「忒修斯之船」:

1世紀時的希臘作家普魯塔克提出了這個問題:如果忒修斯的船上的木頭逐漸被替換,直到所有的木頭都不是原來的木頭,那這艘船還是原來的那艘船嗎?這類問題現在被稱做「忒修斯之船」。

回到原來的 tweet 上看才笑了出來。

另外補充一下,「」這個字念「特」,應該會有人想查,這邊附上連結。

Wikimedia 新計畫:WikiFunctions

Wikimedia 的新計畫 WikiFunctions:「Introducing Wikifunctions: first Wikimedia project to launch in a decade creates new forms of knowledge」。

官方的說明中提到 WikiFunctions 是提供給 Wikimedia 其他的計畫用的程式碼:

Wikifunctions is a Wikimedia project for everyone to collaboratively create and maintain a library of code functions to support the Wikimedia projects and beyond, in the world's natural and programming languages.

這樣有點抽象,看「Wikifunctions:Catalogue」這邊的範例會比較具體一點,可以看到都是實作很基本的功能,像是「Function: To Uppercase」。

Hacker News 上也有討論:「Wikifunctions (wikimediafoundation.org)」,在 id=38549081 這邊有人比較清楚的說明了要解決的問題:

A lot of Wikipedia sites have scripts embedded in the wikitext which automatically generate or transform information on a page, e.g. automatically performing unit conversions to generate text like "I would walk 500 miles (804.67 km)", performing date math to automatically generate and update a person's age based on their birthdate, or querying structured data from Wikidata [1] to display in an infobox. One example of these scripts is the {{convert}} [2] template on the English Wikipedia.

Initially, these scripts were written in MediaWiki template logic [3], and were maintained individually on each wiki. This quickly proved unmaintainable, and some of those scripts were rewritten in Lua using the Scribunto extension [4], but these were still per-wiki, and there were frequently issues where different wikis would copy scripts from each other and introduce their own incompatible features.

The WikiFunctions project is an attempt to centralize development of these scripts, much like how Wikimedia Commons [5] centralizes hosting of freely licensed images and other media.

MediaWiki 本身的 template engine 還是有極限,所以很多的需求會希望使用程式語言開發,一方面是比較好維護,另外一方面是效率也比 template engine 硬幹來的好。

先前大家在 MediaWiki 上比較常用的方案是透過 Extension:ScribuntoLua script,而這個 extension 後來變得太重要 (好用),直接包進 MediaWiki 了。

拿個例子來說,常見的引用功能 Template:Citation 裡面直接是透過模組實作:

<includeonly>{{#invoke:citation/CS1|citation
|CitationClass=citation
}}</includeonly><noinclude>
{{Documentation}}
</noinclude>

而這邊的 #invoke 就是去使用「Module:Citation/CS1」這邊的 Lua 程式。

目前的架構上面,每個語言的 Wikipedia 都需要使用 Lua 維護自己的 Module:*,而 WikiFunctions 計畫則是希望能夠整合起來,算是重新打造基礎建設的工程。

目前看了一些 WikiFunctions 的實作,主要是以 PythonJavaScript 為主。

這樣看起來,技術上是蠻有機會讓 Scribunto 退役,但實際上要不要這樣推還沒查到討論,在 Wikifunctions:FAQ 這邊則是沒提到 Scribunto,不確定是不是想雙軌跑...

改善 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 Commons 發現的印度異常流量

Hacker News Daily 上看到「Investigate unusual media traffic pattern for AsterNovi-belgii-flower-1mb.jpg on Commons」這個,維基百科拿來存放各種多媒體檔案的 Wikimedia Commons 發現有大量的印度流量都打進了 https://upload.wikimedia.org/wikipedia/commons/thumb/1/16/AsterNovi-belgii-flower-1mb.jpg/1280px-AsterNovi-belgii-flower-1mb.jpg 這張圖片,而這佔了 EQSIN (新加坡伺服器的代碼) 中 20% 的流量:

由於 User-AgentReferer 都沒有資訊,可以確認這不是瀏覽器造成的流量,但也因為沒有有用的資訊,變得很難查。

接下來有使用者提到時間點可能跟 TikTok 在印度被 ban 有關,因為在被 ban 後有很多使用者會去找替代的服務,而開發者有可能就直接拿這張圖來當啟動畫面或是背景畫面。

所以他們把熱門的替代服務都看了一輪,也都沒看到這張圖。後來他們猜測有可能是抓了但沒顯示在畫面上,所以開始交叉測試:在開 app 後就去 Hive 掃 HTTP log,然後找到一個 app。

後來為了要確認是不是這個 app,他們架了一組 DNS server 記錄查詢的網域名稱,看看 app 會不會觸發查詢 upload.wikimedia.org 這個網域名稱,而不出所料的確認了,而且真的就是在啟動時有抓,但是沒有顯示在畫面上。

接下來就是想辦法聯絡開發團隊,而目前 Wikimedia Commons 這邊先以 User-Agent 擋掉這些需求了。

另外在 Hacker News 上的討論「20% of requests for Wikimedia Commons are for one image of a flower (wikimedia.org)」也很有趣,有其他事件的苦主在當年遇到 MSN 直接用他網站上的圖片導致他的伺服器快掛,而且反應了很多次都沒用,然後他就把圖片換成「Netscape Now」,然後十五分鐘內就被解決了:

At the height of the browser wars I once woke up to Microsoft hotlinking a small button for downloading our software from the MSN homepage. I tried to reach someone there for hours but nobody cared enough to do something about it. The image was small (no more than a few K), but the millions of requests that page got were enough to totally kill our server.

Finally, I replaced the image on there with a 'Netscape Now' button. Within 15 minutes the matter was resolved.

找了一下圖片,看起來應該是類似這種的圖:

要直接反擊讓人會痛... XD

維基基金會的 Git Server 從 Gerrit 換到 GitLab

這兩天受到注意的消息,維基基金會決定把 Git Server 從本來的 Gerrit 轉換到自建的 GitLab 上:「GitLab consultation」,在 Hacker News 上也有不少討論 (i.e. 戰文):「Wikimedia is moving to Gitlab (mediawiki.org)」。

先從官方的說法開始看,主要是 Gerrit 的運作方式與目前業界與社群的常用方式不同,也導致了 usability 不怎麼好,這使得社群與基金會的員工的學習成本偏高:

While Gerrit’s workflow is in many respects best-in-class, its interface suffers from usability deficits, and its workflow differs from mainstream industry practices. This creates barriers to entry for the community and slows onboarding for WMF technical staff.

另外也發現內部很多人會直接用外部的 Git 服務,了解後主要列出三個原因:

  • lower friction to create new repositories
  • easier setup and self-service of Continuous Integration configuration
  • more familiarity with pull-request style workflows

再來就是尋找與選擇的過程了,但其實市場上也沒什麼可以選的,從說明的 FAQ 部份可以看到 GitHub 與 GitLab,另外因為基金會的特性有強烈偏好 open source self-hosting 方案,基本上就是 GitLab 了...

不過如果是因為 code review 而決定換過去的話,我猜不完全是工具的問題,內部應該有不少政治上的問題,只是外面這次看不出來而已。

在 Hacker News 上的討論還蠻有趣的,有些前員工的發言點出了在 code review 時遇到的問題看起來不是這次換成 GitLab 可以解的。