Wiki周りを色々修正

コメントを残す

がさごそ修正

雑談雑談ー。

304 Not Modified処理をrefプラグインに組み込み
　PukiWikの場合、画像をUploadしてWiki上のページに表示できます。セキュリティの問題上、画像等はファイルへの直接のリンクではなく、refプラグインを介して呼び出されています。これは普通問題は無いのですが単一ページに画像をたくさん表示した時に足かせになります。『プラグインを介して～』という事は即ち画像と同じ数だけPHP Scriptが走らされるという事です。これは何が問題なのかというと、勿論サーバ負荷の問題も一つありますが、レンタルサーバによっては同時に実行するプロセス数1を制限しているものがあります。また同時リクエスト数制限を行っている可能性も有ります。それらに引っかかると、画像が表示されなくなったりサーバエラー(500や503等)が表示されるでしょう2。サーバに多くの利用者を詰め込んでいる廉価サーバ程これは顕著に現れるでしょう。多分経験のある方も多いのではないでしょうか。そのような制限は共用サーバではどうしても必要なものなのですが、利用者にとっては不便に違いありません。この問題の回避をいくらか期待できる方法があり、これが “Last-Modified”ヘッダと”If-Modified-Since”ヘッダを使う方法です。

　これは、はじめのサーバからのファイル送信時に『このファイルの更新時間は～だよ』(Last-Modified)を送り、ブラウザ側は再度それをサーバから取ってくる時に『前にリクエストした時、このファイルの更新時間は～だった。もしそれより新しかったら頂戴』(If-Modified-Since)と送信します。サーバ側はこの申告をチェックして『前に見た時より新しくなっているから送信するね』と新しいファイルを送信するか、『前と変わって無いや、キャッシュを利用してちょ』(304 Not Modified)というような感じのやり取りで実現されます。これにより転送量が節約できるのは勿論ですが上述のrefプラグインの件に関しても同時起動数や同時接続数の節約およびWiki閲覧の快適化が期待できます3。

　分かっている人には何を今更(しかもかなり適当)、分からない人にはチンプンカンプンかもですが、本題はここから。上記の事実は把握はしていたのですが、PukiWikiも或る程度は実装しているだろうと思って気にしてませんでした。しかし、ふとrefプラグインのコードと実際のHTTP通信の様子を見たら……あれ、もしかして実装されてない？そういう訳でがしがしと改造しました。実際に画像の多いページで試すと表示終了までかかる時間が短縮されていますので効果はあるようです4。実際のHTTP通信の様子も期待通りになっています。とりあえずは成功ということでしょう。あとは本来のサーバ負荷やらの部分で改善が図れるかという点です。まあ、z49.org以下のWikiにはあまり画像は無いので殆ど意味は無いかもしれませんし、独学＆資料の勝手解釈で修正したので必ずしも実装が正しく出来ているかは自信ないですが5、とりあえず問題ないので良しとしましょう。

　しかし、ぽんこつな私が片手間でも書き上げられるコードなのにOfficcialで実装されていないのはなぜなのか多少気になるところです。何らかの問題があったのかもしれません。あと、PukiWikiのページ表示自体にもLast-Modifiedを送信する機能はあるのですが6、これはいまいち活用されていないように見受けられます7。ブラウザ側の『前の更新時間から～時間以内は再リクエストせずキャッシュから読む』みたいな挙動を期待しているのかなぁと思いますが、このいわゆる『ブロードバンド時代』ですし大抵は『Webサイトを表示するたびに確認する』のような設定にしている方も多いでしょうから効果は薄い気もします。ページ表示自体にもこの仕組みを組み込むことは試してみて動く事は確認したのですが8、pluginではなく本体部分の改修で影響範囲がつかめない9ので修正はちょっと躊躇しています。PukiWikiのプログラム構造を完全に把握していませんし。

Fallout New Vegas Wiki JP設置
　Bethesdaファンの私がやらない訳無いじゃないですか！
という訳で設置してみました。色々今まで検討した修正を突っ込んであります。

　URIは以下になります。
http://newvegas.fallout.z49.org/
いつもこの辺のサブドメインの選定は悩んでしまいます。URIは出来るだけ短くすべきなのですが、分かり難くなってもいけません。他に候補は

1) wiki.newvegas.fallout.z49.org
2) wiki.nv.fallout.z49.org
3) falloutnewvegas.z49.org
4) fallout-newvegas.z49.org

と考えましたがどれもいまいちな印象で却下しました10。

　中身はFallout 3 Wiki JPのものをかなり転用しています。というか、そのログからFallout 3なものをばっさり削除した形です。Fallout 3の時もOblivionの転用だったのでまぁ問題は無いでしょう。

  1. Scriptもしくはプログラムの数と読み替えても良い [↩]
  2. デフォルトのPukiWikiはCSSもPHP Scriptであるので同じくこの問題に影響される。解決策として通常のCSSファイルに変更する方法もよく用いられる [↩]
  3. ファイルが更新されてなければScriptをそこで即座に終了出来る為 [↩]
  4. wiki.oblivion.z49.orgのMOD/特集記事/VWD_Mod比較/検証 等 [↩]
  5. refプラグインのみ手を加えてattachプラグインはそのままなので実質にはページに貼り付けた画像の表示にのみ関係する修正。attachプラグイン経由でDLや画像の表示を行う場合は無関係。画像のキャッシュがおかしいと思う場合はattachプラグイン経由で確認すればよい [↩]
  6. pukiwiki.ini.php $lastmod [↩]
  7. If-Modified-Sinceを受け取って処理する部分がPukiWikiのどこにも無い。更にデフォルトで”Cache-control: no-cache”, “Pragma: no-cache”なんてヘッダを送信している(skin/pukiwiki.skin.php)。確かに普通のファイルはキャッシュが変かなと思ったらURI末尾に”?”をつけてリクエストすれば簡易的に確認できるが、PukiWikiの場合は同じ方法が出来ないのでローカルキャッシュクリアしか方法が無いが [↩]
  8. lib/html.phpのcatbody()の前の方で行えば良い [↩]
  9. 現時点で、include等のプラグインを使ったページ等の場合は処理が面倒な事は確認済 [↩]
  10. 1は一番明快だが長すぎ。2は長さの元凶を短縮したが訳が分からなくなっただけ。3は英語圏では普通だけどキャメルケースな記法(FalloutNewVegas.z49.org)にしないと激しく可読性が悪い。4は分かりやすいが今までの管理サイトのパターンから外れるので微妙。そもそもドメイン文字列も基本的にはドットで区切られた階層構造的設計が普通 [↩]

コメントを残す

メールアドレスが公開されることはありません。