雑記帳 - JasminInfo

CGI(PHP)とCacheやLast-Modified

ECO-Wiki (acronia) 設定メモで $lastmod = 1; の設定をしてみましたが、BugTrack/763-負荷対策のまとめ-キャッシュを生かすをみると、これだけではIf-Modified-Sinceの判定などは行われないとのことで、あまり意味がなさそうでした。

そこで、実際に確認してみました。まず、初回アクセス。

[Request]
GET /wiki/ HTTP/1.1
Host: eco.acronia.net
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive

[Response]
HTTP/1.1 200 OK
Date: Wed, 19 Nov 2014 12:58:24 GMT
Server: Apache/2.2.25
Cache-Control: no-cache, max-age=10
Pragma: no-cache
Last-Modified: Sat, 15 Nov 2014 14:57:47 GMT
Expires: Wed, 19 Nov 2014 12:58:34 GMT
Keep-Alive: timeout=5, max=20
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=EUC-JP

確かに、Last-Modifiedは出力されています。また、no-cacheも返しているのでPukiWikiとしてはキャッシュして欲しくなさそうです。

そして、2回目のアクセス。

[Request]
GET /wiki/ HTTP/1.1
Host: eco.acronia.net
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
If-Modified-Since: Sat, 15 Nov 2014 14:57:47 GMT

[Response]
HTTP/1.1 304 Not Modified
Date: Wed, 19 Nov 2014 12:58:02 GMT
Server: Apache/2.2.25
Connection: Keep-Alive
Keep-Alive: timeout=5, max=17
Expires: Wed, 19 Nov 2014 12:58:12 GMT
Cache-Control: no-cache, max-age=10

ブラウザはIf-Modified-Sinceを送っていました。no-cacheは「キャッシュしても良いけど毎回確認してね」くらいの意味合いなので、この挙動自体はまあ普通です。*1

そして、なぜかレスポンスは「304 Not Modified」。つまり、サーバー側でIf-Modified-Sinceを解釈して更新されていないと返答したことになります。しかし、PukiWikiのソースコードを探してもそんなことをしている記述はなさそう、う～ん(ーー;)

そこでもっと調べてみると、どうやらスクリプトがLast-Modifiedを返すと、CGIがIf-Modified-Sinceと比較してNot Modifiedかどうか判断してくれる、らしいです。なにそれΣ('◇'*)

ただ、phpスクリプトはIf-Modified-Sinceなんか見ずに普通に動いている訳なので、

• Not Modifiedでもサーバー側のCPU負荷とかはたぶん通常と同じだけかかる
• データは送られないので、通信量は削減できる

ということになるでしょうか。う～ん、微妙(･･?)

そして、問題なのはPukiWikiのLast-Modifiedは、#pcommentや#include*2を見ていないので、コメントが書き込まれてもキャッシュが更新されずにそれが見えないという現象が起こります(;^_^A

というわけで、$lastmodの設定は元に戻すことにしました。

ちゃんとキャッシュするには？

クライアントキャッシュをちゃんと使うなら、以下の対応が必要でしょうか。

• phpスクリプトでIf-Modified-Sinceを見て、Not Modifiedなら処理をスキップする
• 以下のどちらかの方法で#pcommentや#includeに対応
  • Last-Modifiedを調べるときに#pcommentや#includeもたどる
  • コメントや被includeファイルを更新したとき、親ファイルの更新日時も変える

#pcommentや#includeもたどるのは、結局ファイルを読む必要があるので負荷を下げたいという目的を考えると微妙です。その点では同時更新が有力ですが、コメントはともかくincludeの対応はちょっと難しいですね。(親ファイルを探す方法を考えないといけない。)

いろいろ手間がかかりそうなのでこれはやらないと思います＾＾；

PukiWiki bodycache

bodycacheの動作テストをしているのですが、これも更新日時判定の問題で#pcommentや#includeが存在するページは対象外とするようです。ただ、#pcommentについては対策パッチが出ています。（親ファイルの更新日時も変える方式。）

#includeを使っているページは少なくないですが、それ以外のページだけでも負荷が減るなら適用してみても良いかな。

リソース状況 その2

• 主なイベント
  • 2014/11/05(水): 公開。
  • 2014/11/14(金)ごろ: 画像ファイルのクライアントキャッシュを有効にした。PukiWikiの設定見直し。
• ページビューはWikiのページ参照を全部カウント（画像アクセスなどはWikiページではないので含まない）。
• CPU使用時間とウェブ転送量は3:00～翌3:00が集計期間。ページビューの集計は0:00～翌0:00。

何とも言えませんが、とりあえず今のところは負荷が増える傾向ではなさそうです。もっとも、次のアップデート後にはアクセスが増える可能性がありますが＾＾；

2014/11/09のアクセス数が妙に多いのは巡回ソフトでのアクセスがあったようです。

画像アップローダー更新

ECO-Wiki用の画像アップローダーのメニュー部とメイン部を独立にスクロールできるようにしました。

その結果、echo.jsがスクロールイベントを拾わなくなったのでちょっと中を弄る羽目に(^_^;)

IE7は見捨てました(。・・。)。全く閲覧できないわけではない感じでしたが…。

各種データベース作成方針

基本的に上から順にやる予定。

データベース

• アイテムデータベース
  • アイテムDB(gamedb)に登録されてたデータの内、装備品以外を登録*1。
  • アイコン表示は（少なくとも最初のうちは）無し。
• 装備品データベース
  • アイテムDB(gamedb)に登録されてたデータの内、装備品をマージ。システムはフィールド追加する以外はそのまま。
    • アイテム説明フィールドと、ふりがなフィールドが必要（ふりがなはアイテムDBとの連携に関係）。
    • 表記揺れへの対応とかでどうしても手作業が入るのでめんどい（；-_-）
  • 装備品DBに登録してしまうとECO Simに表示される装備品が増えてしまうのが懸念点。
    • 使いにくそうになったらフィルタでも付ければ良いかな。
    • データ量は倍になるくらいならたぶん大丈夫*2。
• 合成データーベース
  • 合成DB(gamedb)のデータを使う。
  • これは（比較的）楽そう。

データベース間の連携

• 合成データーベースと他のデータベースの連携
  • アイテム/装備品データベース上に合成レシピを表示。
    • 入手方法(生成物の場合)や備考(材料の場合)の所にレシピを表示するイメージ。
    • ひも付けはアイテム名でマッチング取る予定（同名アイテムが問題になることはたぶん無いはず）。
    • これは便利そうなのでやりたい。
• アイテムデータベース＆装備品データベース
  • アイテムデータベースを表示したとき、装備品データベースのアイテムもマージして表示。
    • アイテムデータベースの流儀にあわせるならふりがなが必要。
    • この機能必要なのかなあ。装備品DBの方で見れば良いような気も。ふりがな足すのめんどい

その他

• アイコン表示
  • 無くてもそんなに困らない気がするけど需要はどの程度なのか……*3。
  • 実装する場合、画像ファイル名はデータベース上のシリアル番号をそのまま使うつもり。
    • メリット:ファイル名をデータベースで保持する必要が無い。ファイル名を考える必要が無い。
    • デメリット: 分かりやすいファイル名を付けられない。同じアイコンを同一ファイルにして使い回せない。

• 設定変更
  • pukiwiki.ini.php
  • default.ini.php
• 見た目周り
  • pukiwiki.skin.php
  • pukiwiki.css (pukiwiki.css.php)
• プラグイン
  • counter.inc.php
  • source.inc.php
  • 追加

続きを読む

ECO-Wiki用画像アップローダー

ECO-Wiki用の画像アップローダーを公開しました。

本当は適当なアップローダーを探して使うつもりだったのですが、良さそうなのが見つけられなかったので結局自分で作ってしまいました(^_^;)

クライアントサイドのアップロード処理の所はpluploadが良さそうだったので使ってみてます。