tracker_listの高速化

  • ページ: BugTrack
  • 投稿者: reimy
  • 優先順位: 普通
  • 状態: 完了
  • カテゴリー: プラグイン
  • 投稿日: 2004-03-18 (木) 22:20:54
  • バージョン: 1.4.5
  • リリース予定バージョン: 1.5.2

メッセージ

tracker_listの出力の高速化も検討課題ですね。出力内容をあらかじめキャッシュするようにできないものか…

official:雑談/10official:雑談/11参照。



2018年2月版 キャッシュ設計(by umorigu)

キャッシュ方針を検討しました。(2018/02/16)

  • 1. 済 各ページからの抽出データをキャッシュする(キャッシュファイルに保存する)
  • 2. 済 テンプレート定義(root),form,page,listのうち、(root),listのページが変更されていない場合にキャッシュを利用する。変更があれば、キャッシュをすべて破棄する
  • 3. 済 各ページは更新時刻をもって変更判定する。(更新時刻が変わっていれば変更されたものとして扱う。仮に内容が変わっていても更新時刻が変わっていなければキャッシュ更新しない)
    • 各ページ・テンプレート定義ページの更新時刻が変わらないことによる誤動作は許容する(利用者・管理者での対策は容易)
  • 4. 済 デフォルトでキャッシュをONにする
  • 5. 済 キャッシュをOFFにするプラグイン設定を設ける
  • 6. 済 UTF-8, PHP5.4 以降の場合のみキャッシュを有効にする(キャッシュをJSONで保存することによる副次制約)
  • 7. 済 (更新判定の高速化) cache/recent.dat を利用してページの更新判定を行う。recent.datに含まれているlist対象ページの更新時刻が、キャッシュのそれと一致すれば、すべてのページが更新されていないと判断する
  • 8. 済 (更新判定の高速化) RecentDeleted を利用してページの削除判定を行うRecentDeletedにlist対象ページが含まれていれば、そのページの情報を再取得する
    • 削除された後復活していない場合: cacheに残っていればcacheからその情報を削除する
    • 削除された後再作成された場合: リストに影響があればrecent.datに情報があるので、Delete時のキャッシュ更新情報としては考慮は不要
  • 9. 済 よく使われる構成で問題なく動作することを目標にし、キャッシュすると問題になるようなケースに対しては、キャッシュをOFFにする手段を提供することで対応する(例: list内にcommentプラグインが挿入されるような特殊ケースを救わない)
  • 10. 済 データ抽出後HTML変換前の各項目・HTML変換後のテキスト、両方をキャッシュする。更新があった場合は前者、全体の更新がない場合は後者を採用する
  • 11. 済 リスト中に他のページへのリンクがあった場合の対応

コメント (副作用のある?パッチ)

  • かなりいい加減ですが… filetracker.inc.php.1.20.diffを試してみてください。 -- ぱんだ 2004-05-07 (金) 20:48:55
    • もっといい方法を募集中です XD -- ぱんだ 2004-05-07 (金) 20:49:24
  • PukiWiki-officialに導入してみました。official:雑談 -- reimy 2004-05-07 (金) 22:08:31
  • なんか、すごく早くなりましたね。 -- upk 2004-05-08 (土) 15:05:55
  • BugTrack/588との合わせ技で、かなり効果が上がったみたい。 -- reimy 2004-05-08 (土) 15:27:27
  • 副作用で、tracker_listが表示されなくなる(ページが真っ白になる)現象があったので、元に戻しました。 -- reimy 2004-05-15 (土) 13:47:18
  • 結局、ぱんださんのパッチはCVSへ取り込まないのでしょうか?おそらくPukiWiki-officialでのホワイトアウトは、func.phpでfunction csv_implodeが定義されていなかった事が原因だったと思います。現に、僕のPukiwiki1.4.4では問題無く動いている様ですが…。このパッチでは解析後のデータがキャッシュされますけど、テーブル書式へ変換済、もしくはconvert_html済のデータがキャッシュできればもう少し高速化できる…かも。(ここまでやるには時間単位でのキャッシュ指定にする必要があるのかな?むしろページ単位でのキャッシュの実装を…) -- 2004-10-22 (金) 19:31:33
    • 上記のパッチを試してますが、私の環境(Pukiwiki1.4.4 , FedoraCore2 + PHP4.3.8)ですと、tracker_listが表示されません。 すいません、表示されないのは私の設定ミスのせいで、パッチ適用を適用したコードが動くことを確認しました。 -- jjyun 2004-10-23 (土) 08:50:53
  • ぱんださんによるパッチの件(2004-05)と、最近の話題(2004-09) がごっちゃになっていましたので、二つに分けました。 -- henoheno 2004-10-23 (土) 21:42:20
  • こちらの件は、実験的な雰囲気であるのと、実際に副作用が出た、というクレームが出ているのと、その副作用の原因追及が行われていないという事でしたので、まるごと避けています。 -- henoheno 2004-10-23 (土) 21:46:18
  • 2004/09にスタートした(以下の)件のように、他にできる事があるならそれをきちんと行う、という方向の改善をまずお願いしたいところで、かつ、いたずらにオーバーヘッド(キャッシュ含む)を増やすのにはあまり賛成しませんが、こちら(diff)の件に中途半端な部分があって、それを明確にしてでもきちんと解決したいというアクションがあルならばもちろん歓迎します :) -- henoheno 2004-10-23 (土) 21:54:54
    • 私が、こちらに提供されているぱんださんのパッチに足りないかもしれないと思う項目は、Config変更後の対応や tracker_list用のcacheの削除方法です。(サーバに直接ログインして、該当ファイルの削除をしなければならないのは大変でしょう) また cacheに書き出す内容としては、一覧への表示項目のみで良いとも考えています(list指定は複数存在可能ですので、cacheはlist単位にも準備する必要がありますけど) -- jjyun 2004-10-24 (日) 08:15:55
  • (余談へコメント) 標準機能としてページキャッシュを実現させようとすると、いつどのように更新すべきかを検知する仕組み、例えば dirty bit が必要で、それをを用意したとして、どのようにして dirty bit をonにさせるかを考えることになります。きちんと実現するならば、プラグイン機構もひっくるめて再設計しなければならないでしょうね -- henoheno 2004-10-23 (土) 21:58:00
    • tracker_list用のページキャッシュとしては、私はそれほど大きな問題に発展させる必要はなく、各ページ毎の更新時間で十分ではないかと考えています。たしかに編集者は各ページの編集時において、該当ページのタイムスタンプを更新しないかもしれません(句読点の修正など一覧に反映させるほどのものではないと判断した場合など)。cacheを適用した場合のtracker_listの振舞いとして、タイムスタンプが更新されなかった場合はそれは更新されてないものとして扱い、厳密な内容の一覧が表示したければ、ページキャッシュを使わない あるいは キャッシュファイルの削除手段が提供されていれば良い と思います。何か見逃している項目があれば教えてください。 -- jjyun 2004-10-24 (日) 08:35:27

コメント (状態ごとにページを分けるのはどうか)

  • 方向性が180度違う気もしますが、状態ごとにページを分けてしまうというのはどうでしょうか。 -- 2004-09-11 (土) 08:47:41
    • それなら質問だけ表示して完了とかは別のページでリンク貼るだけかなぁ。実質見るのは質問ですからね。 -- 2004-09-11 (土) 11:41:07
  • 「特定の状態だけ表示できる」様にすれば、どちらも適えられそうですね。 -- henoheno 2004-09-11 (土) 12:04:07
    • フィルター機能を使うと見やすくなるとは思いますが、現状だと下位層のページ内容を確認するindexのようなファイルがないので、1つ1つ見て振り分けるような方法しかないと思うのです。あくまで想像ですが、期待するほどあまり速くならないのでは?と思っています。(PukiWiki-officialのような数百ページものコンテンツを作って確認したわけではないので、あくまで想像ですが) -- jjyun 2004-09-11 (土) 12:30:13
  • devのでよければ、送りますが(なんて書いてみるテスト) -- henoheno 2004-09-11 (土) 22:08:21
    • すぐできるかどうかわかりませんが、テストデータとして提供していただけるのであれば、ページ生成時間がどの程度異なるのか確認してみますよ ;)(でもちょっとデータ量が半端じゃなかったりして...とちょっと心配 (^^; ) -- jjyun 2004-09-11 (土) 22:40:22
  • 今回の目的に必要なのは wiki ディレクトリだけなので、それだけであれば特に問題ないと思いますので、圧縮してお送りして本日のバックアップ作業に代えさせていただこうか、なんて思ったのですが、連絡先がわかりませんでしたのでメールか何かでアドレスをお教え下さい。 -- henoheno 2004-09-11 (土) 23:44:18
    • http:// sourceforge.jp/projects/pukiwiki/ ページから辿れる henohenoさんの紹介ページにありましたアドレスへ連絡先を送付しておきました。ご確認お願いします。 -- jjyun 2004-09-12 (日) 00:30:24
  • 受け取りました。送りました。色々遊んでやって下さい。軽くできそうなところがあれば、ぜひ :) -- henoheno 2004-09-12 (日) 01:08:34
    • ありがとうございます、頂きました。大雑把ですが確認してみた結果を以下にまとめまてみましたので御覧ください。:) -- jjyun 2004-09-12 (日) 11:34:18
    • コンテンツの内容(html)を作るのに、結構 時間やリソースががかかっているとは思いませんでした。 -- jjyun 2004-09-12 (日) 11:39:29
  • うほっ、いいtrackerの速度・・・。あんなに変わる物なのかぁ。 -- 2004-09-12 (日) 13:31:33
    • そもそも違いが出るなんて思っていなかったので、私もびっくりです。自宅で使っているクライアントマシン上なので、参考値として見ていただければと思います。あと使用したtrackerの修正版は、公開中のスクリプトではなく、近日公開予定のVerのスクリプトで試しています。(速度改善のための修正をしたわけではないので、以前のでもさほどかわらないと思いますけど :)) -- jjyun 2004-09-12 (日) 13:50:06
  • メモリのオーバーヘッドが相当あるのではないかと思っています。 -- henoheno 2004-09-12 (日) 22:30:19
  • まだパッチは読んでおりませんが、フィルタリングを行うための機能を、うまく呼び出せる様にするCLIの部分をうまくすれば、結構価値が出そうですね。よかったよかった。 -- henoheno 2004-09-12 (日) 22:31:53
  • こいつをPukiWiki-officialに実装させればより快適に!? -- 2004-09-16 (木) 08:18:54
  • この件、本家本元のぱんださんに確認をお願いしました(開発日記/2004-09-14)。そうですね。PukiWiki-officialには向いていますね :) -- henoheno 2004-09-16 (木) 08:22:43
  • …というか、すでにjjyunさんのほうが詳しいような気がしますが :D -- ぱんだ 2004-09-16 (木) 19:31:31
    • いえいえ、そんなことはありません。ぱんださんのコードを使ってPHPの勉強をさせてもらっているのです。*1 -- jjyun 2004-10-22 (金) 23:39:57
  • ポケットを叩いて、ビスケットが2つに割れたのです。あれ? -- henoheno 2004-09-16 (木) 20:44:03
  • (2004-05時点のパッチの話題は上に移動しました)
  • こちらの件のステータスは、ぱんださんにお願いしたところまでですよ -- henoheno 2004-10-23 (土) 22:29:03
    • henohenoさん、ぱんださんへ > すいません。Ver1.0での改修でバグが入り込んでいて特定の条件下では正しくフィルタ機能が動いていませんでした。
      cache機能を追加したスクリプト(Ver1.1)の公開直前だったので、Ver1.1の内容を見ていただけないでしょうか?*2 また Code Reviewにおいて何か不都合があれば御連絡ください。(カスタマイズしたコードにある、パッケージプラグインになっていないlistbox3, datefield等に対応したコードが邪魔していないかと、ちょっと気になっています) -- jjyun 2004-10-31 (日) 19:50:11
  • PukiWiki-officialの続質問箱にも入れればいいのに・・・ -- 2005-03-26 (土) 21:32:01

tracker_listの速度改善に対する、フィルター機能の有効性の検証

  • 各計測対象の紹介
    番号調査対象測定環境備考
    0bugtrackPukiWiki.dev
    PukiWiki 1.4.4/ PHP 4.1.2
    測定時間 2004/09/12 06:50~
    1bugtrackMyHost
    PukiWiki 1.4.4/ PHP 4.3.8
    OS:Fedora Core2
    2tracker default/no-filter同上memory_limit=8M→12M
    3tracker modified/no-filter同上memory_limit=8M→12M
    4tracker modified/完了,却下 を除外同上memory_limit=8M
  • 測定結果(単位はsec. ページ下に表示される HTML convert time の値です)
    測定回数0:1:2:3:4:
    bugtracktracker
    対象ページ数670670670670154
    1回目5.5327.54032.93145.62618.181
    2回目5.5697.00335.85341.68916.489
    3回目6.2026.96537.29437.98517.992
    4回目5.0007.02128.89338.87513.471
    5回目6.4477.23943.58038.66216.869
    平均5.7507.15435.71040.56716.600
  • メモリ割り当ての失敗時のメッセージ
    • memory_limit = 8Mの時
      PHP Fatal error:  Allowed memory size of 8388608 bytes exhausted (tried to 
      allocate 48 bytes) in <pukiwiki-path>/lib/make_link.php on line 664, 
      referer: http://<test-locale>/index.php?cmd\=edit&page=BugTrack2
    • memory_limit = 10Mの時
      PHP Fatal error:  Allowed memory size of 10485760 bytes exhausted (tried to
      allocate 30683 bytes) in <pukiwiki-path>/lib/convert_html.php on line 79, 
      referer: http://<test-locale>/index.p\hp?cmd=edit&page=BugTrack2
  • 参考:myHost のスペック
    項目
    CPU info/proc/cpuinfo より抜粋
    model nameCeleron (Coppermine)
    stepping10
    cpu MHz1102.815
    cache size128 KB
    Memory Info/proc/meminfo より抜粋
    mem total509036 kB
    mem free118848 kB
  • (ページデータが、trackerのdefault/page テンプレートに合致していないため)trackerのリスト表示がおかしくなるページが、散見されましたが正しくlist表記できるように修正してはいません。
    以上の測定結果から、以下のように結論づけることができると思います。 -- jjyun 2004-09-12 (日) 11:19:14
    • bugtrack/bugtrack_listの方が速くリソースを消費しない
    • tracker/tracker_listの方は、カスタマイズができる反面、リソースを消費し、処理速度も遅い。しかし一覧の対象となるページ数を抑えるよう適切なフィルタリングをかけることで、これらを改善することは可能

  • 2017/10/24現在、officialのofficial:質問箱official:質問箱5のページを全部合わせると 2594 ページあります。これらを統合しても現実的な速度で表示できる程度には速くしたいと考えています -- umorigu 2017-10-24 (火) 03:04:13
    • 考えてみましたが、2000件越えのlistを高速に処理しようとするとキャッシュの仕組みが複雑になりすぎるので、標準プラグインのtracker_listはbugtrack_listと同程度の対応にして、PukiWiki-officialには専用のプラグインを作成することにします -- umorigu 2017-11-18 (土) 22:52:33

コメント (2018年2月版キャッシュ実装 by umorigu)

  • tracker_listに対してキャッシュを実装しました commit:e4edb2f0ad これまで議論されていた内容を実装したものです。フィルタ機能は実装していないので巨大なリストに関しての効果は限定的かもしれません。(PukiWikiは巨大なtableのレンダリングが遅い) -- umorigu 2018-02-27 (火) 03:38:39
  • PukiWiki-officialに対して仮適用してみました。条件のいいとき(サイト全体の更新がないとき)は10倍程速くなっているようです。 -- umorigu 2018-02-27 (火) 04:25:27
    • キャッシュなし: pukiwiki.osdn.jp/_o_560_before/?%E8%B3%AA%E5%95%8F%E7%AE%B13 (6-11秒)
    • キャッシュあり: pukiwiki.osdn.jp/_o_560_after/?%E8%B3%AA%E5%95%8F%E7%AE%B13 (0.3-0.6秒)
  • 表組みが遅い件はBugTrack/2457として別に登録しました -- umorigu 2018-02-27 (火) 23:33:08
  • BugTrack/2457で判明した遅い原因を解消しました。ページリンク用のtimestamp取得にキャッシュを使うようにし、部分更新(ページの追加更新)がある場合でも1秒程度で表示できるようになりました -- umorigu 2018-03-01 (木) 05:52:42
    • キャッシュなし: pukiwiki.osdn.jp/_o_560_before/?%E8%B3%AA%E5%95%8F%E7%AE%B13 (6-11秒)
    • キャッシュあり: pukiwiki.osdn.jp/_o_560_after2/?%E8%B3%AA%E5%95%8F%E7%AE%B13 (0.3-0.6秒)(部分更新の場合:1秒)
  • こんにちは。ささいな事ですが設計上の問題があります。個別のJSONフォーマットのキャッシュファイル "cache/ページ名.tracker" の拡張子の文字数が長いので、勘違いでなければ、極端に長すぎるページ名についてキャッシュファイルを保存できない不具合が生じる可能性があるかもしれません。 -- henoheno 2018-03-03 (土) 07:37:07
    • Tracker対象のページのキャッシュ(今回使った .tracker)のファイル名よりも、Tracker配下の各ページのwikiファイル(.txt)の方が長くなるので、今回の対応によって問題が増えたということはありません。ただ、別件としてページ名長さ制限は設定したいところではあります BugTrack/84 -- umorigu 2018-03-03 (土) 21:55:30
  • BugTrack/2457 で判明した遅い原因」が何なのかは BugTrack/2457 に書かれていないように見え、コミットログにも無さそうなので、よくわかりません。 -- henoheno 2018-03-03 (土) 07:38:28
    • 「ページリンクを生成するのにページの更新日時を取得しているために tracker_list, bugtrack_list では遅さが目立つ」がその記述になります。tracker_list 対象が1000ページあったとすると、ページリンクを生成するためにファイルシステムアクセスである is_page() と get_filetime() がそれぞれ最低1000回呼び出され、これが遅いということでした。実装をpushしました commit:3e9aff6511 -- umorigu 2018-03-03 (土) 22:13:58
  • これは快適な出力速度ですね :) -- henoheno 2018-03-03 (土) 07:43:38
  • 元々「レイアウトが異なる複数のtrackerが同一のページを抱える(trackerの入れ子や、部分共有)」ような使い方を想定していません。基本レイアウトによって全ての情報をキャッシュさせるようにして、部分抽出レイアウトによってページや項目の抽出を行う程度の重ね合わせについては現実的かもしれませんが、カスタマイズが必要かもしれません。 (将来の質問に対する空想に基づいた回答) -- henoheno 2018-03-03 (土) 07:55:54
    • 元々のtrackerの特性としてconfigのうち(root),pageが異なる別の trackerが同じページを参照することは考慮されていません。listについてはtracker_listは別listテンプレートで同一traker項目になっても動作します。今回のキャッシュは、複数listに対して誤動作こそしませんがキャッシュがあまり有効に利用されません。(最後に表示したtracker_listのlistベースでキャッシュファイルが再生成される) おそらく実運用では存在しない程度のレアな状況なので基本的には考慮しなくてもいいと考えます -- umorigu 2018-03-03 (土) 21:49:59


*1 ただ、ちょっと今戸惑ってる部分があります。$config->config_name という部分がいくつか見受けられますが、Config class には config_name というメンバーはありませんよね,.もしかして間違い?!
*2 Ver1.1ではコードの改修の他に、改修・追加部分のインデントを、元のコードにあわせるように直しました

添付ファイル: filetracker.inc.php.1.20.diff 1223件 [詳細]

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-03-08 (木) 22:56:23
Site admin: PukiWiki Development Team

PukiWiki 1.5.1+ © 2001-2016 PukiWiki Development Team. Powered by PHP 5.6.37-0+deb8u1. HTML convert time: 1.757 sec.

OSDN