2013-08-07 130 views
1

通過transclusion我的意思是像Mediawiki:很多轉換讓頁面加載速度變慢?

{{template 
| blahblah= 
| asd = 
| df= 
}} 

頁所以,如果有太多的「|」 S,然後將它們使頁面加載慢?

假設頁 「模板:*」 是

* 

使{{*}}將呈現一個子彈。

請比較

(模板:A和頁面 「A頁」)

(模板:B和頁面 「B頁」)

加上頁面和B頁面將顯示相同的內容,但是如果以這種方式進行數千次更改,哪一個會更快加載?

模板:一個

* {{{a}}} 
* {{{b}}} 
* {{{c}}} 

一個頁面

{{A 
|a=q 
|b=w 
|c=e 
}} 

模板:乙

{{{a}}} 

B頁數

{{B 
|a={{*}} q <br> {{*}} w <br> {{*}} e 
}} 

=====問題補充==============

@llmari_Karonen非常感謝。

  1. 如果什麼數量幾乎是1000,這樣一個頁面是

    {{A | A1 = Q | A2 = W | A3 = E .... | A999 = W | A1000 = H }}

    不過,由於高速緩存, 「對於大多數網頁瀏覽,模板transclusion對性能沒有影響」?

  2. 你是什麼意思的「大多數頁面瀏覽量」?你的意思是足夠低的瀏覽量?

  3. 你說過「推薦部署MediaWiki的方法是在反向緩存代理之後或使用文件緩存,它們中的任何一個都會在分析器緩存前添加額外的緩存層。

在「發佈mediawiki上的任何內容之前應該這樣做嗎?或者,在我將所有網頁發佈到mediawiki後,如果我這樣做並不重要?

===如果該transclusion關係是非常複雜的===

@llmari_Karonen我有一個問題。如果這個跨界關係非常複雜呢?

例如

網頁A是

{{臨時 | ~~~ | ~~~ ...(相當多) | ~~~ }}

而且模板:臨時有{{TEMP2}},

和模板:TEMP2再次

{{TEMP3 | ~~~ | ~~~ 。 ..(非常多) | ~~~ }}

即使在這種情況下,由於您提到的原因,很多轉換不會影響頁面A的加載速度?

回答

2

是和否。大多數沒有。

是,在一個頁面上大量的模板transclusions的不放慢有些分析,一方面是因爲模板需要從數據庫加載,因爲他們需要每一個他們用時間來重新分析。然而,有很多caching事情:

  • 一旦一個樣板是在特定網頁上transcluded一次,它的源代碼被緩存,使得頁面上的同一模板的進一步transclusions不會再造成任何數據庫查詢。

  • 對於使用的模板而沒有參數,MediaWiki也緩存解析後的模板形式。因此,在你的例子中,{{*}}只需要解析一次。

  • 在任何情況下,一旦頁面被解析一次(通常是在某人編輯它之後),MediaWiki caches the entire parsed HTML output將其重新用於後續頁面視圖。因此,對於大多數頁面瀏覽而言,由於頁面將不需要重新分頁,所以模板轉換具有沒有對性能的影響。 (但是,請注意,默認parser cache lifetime是相當低的。對於像維基百科這樣的高流量wiki,默認值是OK,但對於小型wiki,我強烈地將recommend增加到例如一個月,並將parser cache type設置爲CACHE_DB。)

  • 最後,部署MediaWiki的推薦方式是在reverse caching proxies之後或使用file cache。這些任何一個都會在解析器緩存前添加一個額外的緩存層。


編輯:要回答你的其他問題:

  1. 不管參數數,每一頁仍然只包含一個模板transclusion(當然,除了{{*}}包含在頁面B,但應該有效緩存)。因此,它們應該或多或少地具有相同的效率(如在實踐中不應該有顯着的差異)。

  2. 我的意思是說,大多數時候當有人查看頁面時,它將(或至少應該)從緩存中提供,因此不需要重新進行修改。的情況下,做發生時,包括:

    • 自頁面最後分析的時間超出$wgParserCacheExpireTime規定的上限(24小時默認,但可以和國際海事組織應爲大多數維基增加) ,

    • 頁面已被修改,因爲它被添加到緩存中,並因此需要被重新解析(這通常是點擊「保存頁面」按鈕後,立即發生),

    • 所用的模板頁面已被編輯,需要納克的頁面進行重新分析,

    • 從這個頁面鏈接的另一頁面被創建或刪除,需要重新分析,從紅色變成鏈接藍色或反之亦然,

    • 頁面使用一個鏈接到MediaWiki擴展故意excludes it from caching,通常是因爲擴展刀片動態變化的內容到頁面,

    • 有人故意purged從緩存的頁面,從而立即重新分析,或

    • 查看該頁面的用戶正在使用不尋常的語言,或者改變了他們偏好中的一些其他選項來影響頁面呈現,導致爲他們生成單獨的頁面緩存版本(該版本可以被任何其他用戶相同的一組偏好,或由同一用戶重訪該頁面)。

  3. 您可以隨時在wiki前添加代理,並/或啓用文件緩存。事實上,由於設置有效的緩存是一項比較高級的任務,因此您可能需要等到您嘗試啓動前未啓用前端緩存的情況下啓動並運行您的wiki。這也使您可以直接比較設置緩存之前和之後的性能。

+0

@llmari_Karonen非常感謝。我還添加了更多的問題,但你能回答這些問題嗎?再次感謝! – user1849133

+0

請參閱上面的修改。 –

+0

@llmari Karonen非常感謝! – user1849133