ためしがき/ecacheテスト

以下、本ページ内の引用部分プラグイン製作者による解説 (魚拓)を元にしています。

ecacheプラグインは何者？

Wiki 文法の出力 HTML をキャッシュし、負荷軽減を試みます。

• サーバ上におけるページの読み込みとHTMLコンバート処理が軽減される。
  • 端末(PC、スマホ等)の負荷が軽くなるわけではない。
• wikiwiki利用者にとってはecacheの使用によりinclude系プラグインの使用上限を緩和できるというメリットがある。

resetオプションの挙動

reset=on|off|new|秒数

reset=on で強制的にリセット。reset=off で常に更新しない。reset=new はページがキャッシュよりも新しければ更新する。デフォルト動作。reset=秒数で指定秒数毎にキャッシュを強制リセット(new の効果もある)。

• wikiwikiにおいてreset=new、reset=offはまともに機能していない？
  • 疑義あり。#recentを使った検証では下記の記載通りMenuBarに追従していたようだが、別途#includexを使った検証をしたところ仕様通り動作しているように見受けられた。
    • 「ecacheの指定範囲内でinclude系プラグインを使用しておらず、純粋な負荷低減が目的の場合」は仕様だけ見るとreset=newで動作させる(resetオプションを省略するか、明示的にreset=newと記載する)のが最も合理的に思えるが、実際には負荷低減にほとんど寄与していないので要注意。
• ecacheの指定範囲内であるページをincludeで囲んでいる場合、includeしたページの更新はecacheのキャッシュが更新されるまで反映されない(reset=3600を指定した場合は反映まで最長で1時間掛かる)。

includeプラグイン上限緩和のしきい値

resetオプションに時間を指定した際の緩和条件として「3600秒超過」と記載されているがreset=3600では緩和されない。reset=3601以上とする必要がある。
→検証ページ

各オプションの利用ケース

• reset=on
  • 基本的にこれを使うことはない。キャッシュを強制的にクリアしたいときのために作られたと思われるが、reset=off以外にしてページを更新すればキャッシュも作り直されるので、reset=onを使うことはない。
• reset=off
  • 後述するpageオプションとセットで使う。pageオプションなしで使うことは基本的にはないはず。
    • 一番使えそうなケースとしては、共通のヘッダ／フッタ（公式番組一覧など）を持つページや、プラグイン製作者による解説にもあるMenuBarだろうか。
• reset=new
  • ecacheの中にincludeがない場合に使う。
• reset=秒数
  • ecacheの中にincludeがある場合に使う。秒数は、アクセス数の多い（1日100以上）ページなら3601、少ないページなら86400など大きめの数字がおすすめ。

pageオプションの挙動

page=ページ名

キャッシュを区別するページ名。デフォルトではカレントページ。MenuBar に設置する場合に page=MenuBar とするためのようなもの。

• これだけだと分かりにくいが、要は「『ページ名』にecacheプラグインで生成されたキャッシュがあればそのキャッシュを参照する」というもの。
• オプション指定がない場合はecacheプラグインを置いているページのキャッシュを参照する。つまりページをまるごとecacheプラグインで囲むような場合はpage指定が不要。
• ページ全体がecacheでキャッシュ化されているページのキャッシュを参照したい場合は以下のように記述する。

  #ecache(reset=86400,page=./子ページ){{
  #include(./子ページ,notitle)
  }}

  • ecacheでincludeごとページ全体をキャッシュ化するような場合と異なり、includeしたページの編集が即座に反映されるメリットがある。
  • このように記述した場合、ecacheのキャッシュはincludeするページ・されるページの双方から更新されることになる。整合性を保つためには以下の条件を満たす必要がある。
    • pageオプションで指定したページ内ではページ全体をecacheで囲む。
    • {{}}内には当該ページのinclude系プラグインのみを設置する。他のものを記載するとそれがincludeされたページ側に反映されてしまうおそれがある。

誤った記述例

#ecache(reset=86400,page=./子ページ){{
*子ページ見出し [#child_page]
#include(./子ページ,notitle)
}}

先に説明した通り{{}}の中身がinclude先に反映されてしまう。次のように書き直す必要がある。

*子ページ見出し [#child_page]
#ecache(reset=86400,page=./子ページ){{
#include(./子ページ,notitle)
}}

ecacheプラグインの使用が逆効果になりうるケース

• 例えば1日のPVが1桁程度のページ(「動画一覧」のような基本的に編集者しか開かないページだとよくある)にてreset=3600でecacheを使用するとかえってサーバの負荷の増やしてしまう可能性がある。
  • アクセス頻度的にキャッシュ再利用がほとんど行えないにもかかわらず、ecacheにより本来は不要のキャッシュ書き込み操作・参照処理を行うことになるため。

結局どう書けばよいのか

include系プラグインを含んでecacheする場合 (40ページ以上)

include系プラグインの上限が解放される最短時間のreset=3601を指定する。

#ecache(reset=3601){{
...
}}

ただ、そもそもの話として、40ページ以上もincludeしているようなページ構成を再検討すべき。まず間違いなく余計な情報をincludeしているはずなので、適切な粒度でページを分割したほうがいい。

include系プラグインを含んでecacheする場合 (40ページ未満)

include系プラグインの上限には引っかかっていないためキャッシュリセットの頻度は任意だが、負荷低減の観点からは上記と同様にreset=3601あたりを指定するのが無難かも。

#ecache(reset=3601){{
...
}}

includeを含まずにecacheする場合

include系プラグインを含む場合はresetで指定した時間がincludeしたページの編集が反映されるまでの最長待ち時間となっていたが、includeを使用しない場合はそのような待ち時間が発生しない。
なのでresetは以下の例に囚われずいくらでも長くすることができる。長ければ長いほどサーバへの負荷が低減される。本来はreset=∞と等価なreset=newを使いたいところだが、現在のwikiwikiでは機能していないため意味がない。reset=∞と等価なreset=newを使えばよい。

#ecache(reset=new){{
...
}}

別ページのecacheを参照する場合

pageオプションの挙動を参照。

#ecache(reset=off,page=./子ページ){{
#include(./子ページ,notitle)
}}

本来{{}}の中身は空欄でよいのだが、ecacheに詳しくない編集者からするとかなり面食らうと思われるので、とりあえず#includeを入れておいたほうが親切。