維基百科:不要擔心效能
![]() |
![]() | 本頁簡而言之:伺服器資源確實很重要,但那是系統管理員們的事情,不要以自己對效能的理解來說事。但如果系統管理員發現問題並進行任何操作但造成了困擾,請不要還原他的操作,並與其溝通。 |
您不需要去關心整個維基站點的效能如何如何。在絕大多數情況下,您自己的力量根本無法使伺服器效能明顯提高或明顯降低。在設計層面上,維基系統也已經阻止使用者做出能夠嚴重影響伺服器效能的行為。
應該關注效能的人都在領薪水,所以您不需要跟著操心了
“ | 網站保持正常執行是我們需要關注的事情。「我們」指的是開發團隊和運維團隊,但是我把這兩伙人相提並論。如果有什麼*需要*使百科全書或詞典正常運作的事情,那就去做吧;如果不確定,那就知會我們一下,如果我們有更簡單的解決方案,我們會採納的。
當然,我們應該用常識來分析問題。如果有什麼明顯會導致嚴重後果的事情,那我們要集中精力檢查。但是,不要大呼小叫,跑來跑去喊「伺服器!伺服器!!」,以此作為不做事的藉口,這樣很蠢的。 |
” |
——Rob Church (MediaWiki developer),wikitech-l, 27 Jun 06 |
維基媒體基金會僱傭了一群IT專家來擔任系統管理員。這些員工有責任保證WMF各維基穩定執行。維基平台是四百台以上伺服器組成的叢集,CPU核心數超過了 2,400,主記憶體總量超過了5T。整個架構已經經過精心設計,能夠把編者對效能帶來的影響降到最低。最重要的是,在叢集上執行MediaWiki軟體、維護WMF各維基內容是叢集設計的根本目的,因此編者們應該放心地按自己的需求和各維基的目標努力。效能不是阻止使用重新導向、避免使用內部連結或停止協同運作的理由。事實上,網站沒有任何內容時伺服器效能才是最好的,但這樣的話要維基百科還有什麼意義呢?
如果系統管理員發現了效能問題,他們自己會處理
“ | 通常情況下,在方針層面上您不應該太關注一些細枝末節的東西,例如模板與伺服器負載什麼的。如果真的耗費效能,我們要麼會修復問題,要麼會在技術層面上進行限制——那是我們的職責……
作為技術問題,我們有責任保持系統執行良好,以滿足網站的需求。換句話說,這不是方針問題。如果我們需要進行限制,我們會實行技術措施…… 除了最極端的情況,方針不應該去關注對伺服器的影響。調整系統、滿足使用者需求是我們的工作。 |
” |
——Brion Vibber (then Wikimedia Foundation Chief Technical Officer),Village Pump, 21 January 2006 |
系統管理員可以訪問大量分析、記錄和管理資料,從而輕鬆地找到效能瓶頸。如果MediaWiki軟體的某項功能對叢集產生了無法忍受的效能影響,MediaWiki開發人員或系統管理員會採取合適的修理措施。目前系統有一些限制就是針對效能問題而引入的,例如限制參照模板的數量和層級、限制頁面大小不能超過2MB、限制刪除超過5,000個修訂的頁面。
有時系統管理員們採取的補救措施不是某種「高科技操作」,而是「普通的」維基編輯。如果系統管理員出於效能原因在維基站內進行了編輯,請不要回退或阻止他們。如果系統管理員要求你做出某些修改,請服從他們的指揮,例如編輯系統介面、封禁使用者和修改高使用量模板。
編者們無法毀掉網站,但管理員們能
“ | 我提了一個普遍適用的建議:不要只憑預言就去大喊「天要塌了,天要塌了!」。
我的意思不是應該忽略已經發現的現實問題, 但等到問題變得現實、真實、可以測算之後,它就很重要了。 |
” |
——Brion Vibber (then Wikimedia Foundation Chief Technical Officer),wikitech-l, 16 January 2007 |
少數情況下,維基百科管理員能夠做出影響網站運轉甚至使網站崩潰的事情(例如mw:User:MZMcBride/Attacks),但是這種事情並不常見,通常也不值得擔心。雖然管理員可以做出難以收拾的惡意編輯,但是不太可能做得出導致資料徹底遺失或者系統徹底損壞的事情。即使遭遇極端情況,只要按照系統管理員的指示進行操作,一切都會好起來。當然,之後您就不要再干相同的事情了。比方說,假如您刪除了Wikipedia:沙盒頁面結果導致網站崩潰,那麼請不要再刪除這個頁面。不過,您也不要「一朝被蛇咬,十年怕井繩」,連修訂版本刪除也不敢再操作。這種恐慌心理對維基百科造成的危害要比一次短暫宕機嚴重得多。
但是,編者們也不是什麼都不用在乎了
“ | 特別是在設計模板方面,最佳化效能是十分重要的,而且對使用者的影響很大。最佳化模板並不難,我自己也時不時地弄一下。但是事情最好還是讓熟悉相關模板和條目的編者們來做。 | ” |
——Tim Starling, MediaWiki Release Manager,wikitech-l, 12 January 2011 |
我們不是說編者們可以把效能問題徹底地拋到一邊,想都不去想,只是不應該因為擔心效能問題而阻礙維基本身運作。如果您熟悉技術,能夠指出最佳化前後差異,那還是應該關注一下效能。假如有個頁面需要等十秒鐘才能載入,刪掉某個模板之後一秒之內就能點進去,並且您能夠重現這個過程,其他人也能確認這個問題,那麼很顯然那個已刪除的模板有問題。想要解決問題的話,自然要竭盡全力最佳化模板。另外,雖然您無法給伺服器叢集帶來明顯的效能影響,但是您仍然可以測試單個頁面的效能,而且開發人員也在一些地方為使用者提供了可以更加準確衡量效能的工具,例如編輯頁面時下方顯示的剖析器分析資料以及防濫用過濾器的組態資料。
本文所指的效能是整個維基站點以及維基伺服器層面上的效能,不是其他方面(例如載入頁面或者使用維基工具)的效能。維基的根本目的是為讀者服務,從服務讀者的角度來講當然也要稍微考慮一下效能的問題。例如您可能需要考慮一下500KB的PNG縮圖與50KB的JPEG縮圖的載入速度問題,不過到底哪一種合適是編者們的問題,開發人員或系統管理員不會鼓勵或阻止編者去做什麼。
總結
“ | 最佳化,依靠的是科學,而不是迷信。 | ” |
——Brion Vibber,wikitech-l, 13 January 2011 |
積極主動地最佳化可以衡量與量化影響的事物,不要擔心你無法測量的事情所造成的效能影響。基金會出錢僱傭的系統管理員會處理整個網站的效能問題。
參見
- 維基百科:不要刪除首頁
- Wikitech 的機器人方針
- MediaWiki效能指導指出了開發人員應當如何關注效能
- 如何讓維基癱瘓掉