tracker_listの高速化†
- ページ: BugTrack
- 投稿者: reimy
- 優先順位: 普通
- 状態: 完了
- カテゴリー: プラグイン
- 投稿日: 2004-03-18 (木) 22:20:54
- バージョン: 1.4.5
- リリース予定バージョン: 1.5.2
メッセージ†
tracker_listの出力の高速化も検討課題ですね。出力内容をあらかじめキャッシュするようにできないものか…
official:雑談/10，official:雑談/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. 済
リスト中に他のページへのリンクがあった場合の対応
コメント (副作用のある？パッチ)†
- 結局、ぱんださんのパッチはCVSへ取り込まないのでしょうか？おそらくPukiWiki-officialでのホワイトアウトは、func.phpでfunction csv_implodeが定義されていなかった事が原因だったと思います。現に、僕のPukiwiki1.4.4では問題無く動いている様ですが…。このパッチでは解析後のデータがキャッシュされますけど、テーブル書式へ変換済、もしくはconvert_html済のデータがキャッシュできればもう少し高速化できる…かも。（ここまでやるには時間単位でのキャッシュ指定にする必要があるのかな？
むしろページ単位でのキャッシュの実装を…） --
- 上記のパッチを試してますが、私の環境(Pukiwiki1.4.4 , FedoraCore2 + PHP4.3.8)ですと、tracker_listが
表示されません。 すいません、表示されないのは私の設定ミスのせいで、パッチ適用を適用したコードが動くことを確認しました。 -- jjyun
- ぱんださんによるパッチの件(2004-05)と、最近の話題(2004-09) がごっちゃになっていましたので、二つに分けました。 -- henoheno
- こちらの件は、実験的な雰囲気であるのと、実際に副作用が出た、というクレームが出ているのと、その副作用の原因追及が行われていないという事でしたので、まるごと避けています。 -- henoheno
- 2004/09にスタートした(以下の)件のように、他にできる事があるならそれをきちんと行う、という方向の改善をまずお願いしたいところで、かつ、いたずらにオーバーヘッド(キャッシュ含む)を増やすのにはあまり賛成しませんが、こちら(diff)の件に中途半端な部分があって、それを明確にしてでもきちんと解決したいというアクションがあルならばもちろん歓迎します :) -- henoheno
- 私が、こちらに提供されているぱんださんのパッチに足りないかもしれないと思う項目は、Config変更後の対応や tracker_list用のcacheの削除方法です。(サーバに直接ログインして、該当ファイルの削除をしなければならないのは大変でしょう) また cacheに書き出す内容としては、一覧への表示項目のみで良いとも考えています(list指定は複数存在可能ですので、cacheはlist単位にも準備する必要がありますけど) -- jjyun
- (余談へコメント) 標準機能としてページキャッシュを実現させようとすると、いつどのように更新すべきかを検知する仕組み、例えば dirty bit が必要で、それをを用意したとして、どのようにして dirty bit をonにさせるかを考えることになります。きちんと実現するならば、プラグイン機構もひっくるめて再設計しなければならないでしょうね -- henoheno
- tracker_list用のページキャッシュとしては、私はそれほど大きな問題に発展させる必要はなく、各ページ毎の更新時間で十分ではないかと考えています。たしかに編集者は各ページの編集時において、該当ページのタイムスタンプを更新しないかもしれません(句読点の修正など一覧に反映させるほどのものではないと判断した場合など)。cacheを適用した場合のtracker_listの振舞いとして、タイムスタンプが更新されなかった場合はそれは更新されてないものとして扱い、厳密な内容の一覧が表示したければ、ページキャッシュを使わない あるいは キャッシュファイルの削除手段が提供されていれば良い と思います。何か見逃している項目があれば教えてください。 -- jjyun
コメント (状態ごとにページを分けるのはどうか)†
- 方向性が180度違う気もしますが、状態ごとにページを分けてしまうというのはどうでしょうか。 --
- それなら質問だけ表示して完了とかは別のページでリンク貼るだけかなぁ。実質見るのは質問ですからね。 --
- 「特定の状態だけ表示できる」様にすれば、どちらも適えられそうですね。 -- henoheno
- フィルター機能を使うと見やすくなるとは思いますが、現状だと下位層のページ内容を確認するindexのようなファイルがないので、1つ1つ見て振り分けるような方法しかないと思うのです。あくまで想像ですが、期待するほどあまり速くならないのでは？と思っています。(PukiWiki-officialのような数百ページものコンテンツを作って確認したわけではないので、あくまで想像ですが) -- jjyun
- devのでよければ、送りますが(なんて書いてみるテスト) -- henoheno
- すぐできるかどうかわかりませんが、テストデータとして提供していただけるのであれば、ページ生成時間がどの程度異なるのか確認してみますよ ;)（でもちょっとデータ量が半端じゃなかったりして...とちょっと心配 (^^; ) -- jjyun
- 今回の目的に必要なのは wiki ディレクトリだけなので、それだけであれば特に問題ないと思いますので、圧縮してお送りして
本日のバックアップ作業に代えさせていただこうか、なんて思ったのですが、連絡先がわかりませんでしたのでメールか何かでアドレスをお教え下さい。 -- henoheno
- http:// sourceforge.jp/projects/pukiwiki/ ページから辿れる henohenoさんの紹介ページにありましたアドレスへ連絡先を送付しておきました。ご確認お願いします。 -- jjyun
- 受け取りました。送りました。色々遊んでやって下さい。軽くできそうなところがあれば、ぜひ :) -- henoheno
- ありがとうございます、頂きました。大雑把ですが確認してみた結果を以下にまとめまてみましたので御覧ください。:) -- jjyun
- コンテンツの内容(html)を作るのに、結構 時間やリソースががかかっているとは思いませんでした。 -- jjyun
- うほっ、いいtrackerの速度・・・。あんなに変わる物なのかぁ。 --
- そもそも違いが出るなんて思っていなかったので、私もびっくりです。自宅で使っているクライアントマシン上なので、参考値として見ていただければと思います。あと使用したtrackerの修正版は、公開中のスクリプトではなく、近日公開予定のVerのスクリプトで試しています。（速度改善のための修正をしたわけではないので、以前のでもさほどかわらないと思いますけど :)） -- jjyun
- メモリのオーバーヘッドが相当あるのではないかと思っています。 -- henoheno
- まだパッチは読んでおりませんが、フィルタリングを行うための機能を、うまく呼び出せる様にするCLIの部分をうまくすれば、結構価値が出そうですね。よかったよかった。 -- henoheno
- こいつをPukiWiki-officialに実装させればより快適に！？ --
- この件、本家本元のぱんださんに確認をお願いしました(開発日記/2004-09-14)。そうですね。PukiWiki-officialには向いていますね :) -- henoheno
- …というか、すでにjjyunさんのほうが詳しいような気がしますが :D -- ぱんだ
- いえいえ、そんなことはありません。ぱんださんのコードを使ってPHPの勉強をさせてもらっているのです。*1 -- jjyun
- ポケットを叩いて、ビスケットが２つに割れたのです。あれ？ -- henoheno
- (2004-05時点のパッチの話題は上に移動しました)
- こちらの件のステータスは、ぱんださんにお願いしたところまでですよ -- henoheno
- henohenoさん、ぱんださんへ > すいません。Ver1.0での改修でバグが入り込んでいて特定の条件下では正しくフィルタ機能が動いていませんでした。
cache機能を追加したスクリプト(Ver1.1)の公開直前だったので、Ver1.1の内容を見ていただけないでしょうか？*2 また Code Reviewにおいて何か不都合があれば御連絡ください。（カスタマイズしたコードにある、パッケージプラグインになっていないlistbox3, datefield等に対応したコードが邪魔していないかと、ちょっと気になっています) -- jjyun
- PukiWiki-officialの続質問箱にも入れればいいのに・・・ --
tracker_listの速度改善に対する、フィルター機能の有効性の検証†
- 各計測対象の紹介
| 番号 | 調査対象 | 測定環境 | 備考 |
| 0 | bugtrack | PukiWiki.dev
PukiWiki 1.4.4/ PHP 4.1.2 | 測定時間 2004/09/12 06:50～ |
| 1 | bugtrack | MyHost
PukiWiki 1.4.4/ PHP 4.3.8 | OS:Fedora Core2 |
| 2 | tracker default/no-filter | 同上 | memory_limit=8M→12M |
| 3 | tracker modified/no-filter | 同上 | memory_limit=8M→12M |
| 4 | tracker modified/完了,却下 を除外 | 同上 | memory_limit=8M |
- 測定結果(単位はsec. ページ下に表示される HTML convert time の値です)
| 測定回数 | 0: | 1: | 2: | 3: | 4: |
| bugtrack | tracker |
| 対象ページ数 | 670 | 670 | 670 | 670 | 154 |
| 1回目 | 5.532 | 7.540 | 32.931 | 45.626 | 18.181 |
| 2回目 | 5.569 | 7.003 | 35.853 | 41.689 | 16.489 |
| 3回目 | 6.202 | 6.965 | 37.294 | 37.985 | 17.992 |
| 4回目 | 5.000 | 7.021 | 28.893 | 38.875 | 13.471 |
| 5回目 | 6.447 | 7.239 | 43.580 | 38.662 | 16.869 |
| 平均 | 5.750 | 7.154 | 35.710 | 40.567 | 16.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 name | Celeron (Coppermine) |
| stepping | 10 |
| cpu MHz | 1102.815 |
| cache size | 128 KB |
| Memory Info | /proc/meminfo より抜粋 |
| mem total | 509036 kB |
| mem free | 118848 kB |
- (ページデータが、trackerのdefault/page テンプレートに合致していないため)trackerのリスト表示がおかしくなるページが、散見されましたが正しくlist表記できるように修正してはいません。
以上の測定結果から、以下のように結論づけることができると思います。 -- jjyun
- bugtrack/bugtrack_listの方が速くリソースを消費しない
- tracker/tracker_listの方は、カスタマイズができる反面、リソースを消費し、処理速度も遅い。しかし一覧の対象となるページ数を抑えるよう適切なフィルタリングをかけることで、これらを改善することは可能
- 2017/10/24現在、officialのofficial:質問箱～official:質問箱5のページを全部合わせると 2594 ページあります。これらを統合しても現実的な速度で表示できる程度には速くしたいと考えています -- umorigu
- 考えてみましたが、2000件越えのlistを高速に処理しようとするとキャッシュの仕組みが複雑になりすぎるので、標準プラグインのtracker_listはbugtrack_listと同程度の対応にして、PukiWiki-officialには専用のプラグインを作成することにします -- umorigu
コメント (2018年2月版キャッシュ実装 by umorigu)†
- tracker_listに対してキャッシュを実装しました commit:e4edb2f0ad これまで議論されていた内容を実装したものです。フィルタ機能は実装していないので巨大なリストに関しての効果は限定的かもしれません。(PukiWikiは巨大なtableのレンダリングが遅い) -- umorigu
- PukiWiki-officialに対して仮適用してみました。条件のいいとき(サイト全体の更新がないとき)は10倍程速くなっているようです。 -- umorigu
- キャッシュなし: 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
- BugTrack/2457で判明した遅い原因を解消しました。ページリンク用のtimestamp取得にキャッシュを使うようにし、部分更新(ページの追加更新)がある場合でも1秒程度で表示できるようになりました -- umorigu
- キャッシュなし: 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
- Tracker対象のページのキャッシュ(今回使った .tracker)のファイル名よりも、Tracker配下の各ページのwikiファイル(.txt)の方が長くなるので、今回の対応によって問題が増えたということはありません。ただ、別件としてページ名長さ制限は設定したいところではあります BugTrack/84 -- umorigu
- 「BugTrack/2457 で判明した遅い原因」が何なのかは BugTrack/2457 に書かれていないように見え、コミットログにも無さそうなので、よくわかりません。 -- henoheno
- 「ページリンクを生成するのにページの更新日時を取得しているために tracker_list, bugtrack_list では遅さが目立つ」がその記述になります。tracker_list 対象が1000ページあったとすると、ページリンクを生成するためにファイルシステムアクセスである is_page() と get_filetime() がそれぞれ最低1000回呼び出され、これが遅いということでした。実装をpushしました commit:3e9aff6511 -- umorigu
- これは快適な出力速度ですね :) -- henoheno
- 元々「レイアウトが異なる複数のtrackerが同一のページを抱える(trackerの入れ子や、部分共有)」ような使い方を想定していません。基本レイアウトによって全ての情報をキャッシュさせるようにして、部分抽出レイアウトによってページや項目の抽出を行う程度の重ね合わせについては現実的かもしれませんが、カスタマイズが必要かもしれません。 (将来の質問に対する空想に基づいた回答) -- henoheno
- 元々のtrackerの特性としてconfigのうち(root),pageが異なる別の trackerが同じページを参照することは考慮されていません。listについてはtracker_listは別listテンプレートで同一traker項目になっても動作します。今回のキャッシュは、複数listに対して誤動作こそしませんがキャッシュがあまり有効に利用されません。(最後に表示したtracker_listのlistベースでキャッシュファイルが再生成される) おそらく実運用では存在しない程度のレアな状況なので基本的には考慮しなくてもいいと考えます -- umorigu
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
tracker.inc.php.1.20.diffを試してみてください。 -- ぱんだ 2004-05-07 (金) 20:48:55
