ページリンクが多数ある場合の表組みレンダリングが遅い†
- ページ: BugTrack
- 投稿者: umorigu
- 優先順位: 低
- 状態: 完了
- カテゴリー: 本体バグ
- 投稿日: 2018-02-27 (火) 23:25:57
- バージョン: 1.5.1
- リリース予定バージョン: 1.5.2
メッセージ†
BugTrack/560でキャッシュを使ってtracker_listの高速化を行いましたが、
PukiWikiの表組みのサーバー側レンダリングが遅いため、表示内容のキャッシュを行っても効果が限定的でした。
ファイルアクセスよりもメモリ上の操作が遅いのは不自然なため、なにかパフォーマンス上大きなボトルネックがあると推測できます。
遅い原因はページリンク(に伴う経過表示のためのファイル更新日時取得)が多いことでした。
(BugTrack/560 より複製)
- 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秒)
- 「BugTrack/2457 で判明した遅い原因」が何なのかは BugTrack/2457 に書かれていないように見え、コミットログにも無さそうなので、よくわかりません。 -- henoheno
- 「ページリンクを生成するのにページの更新日時を取得しているために tracker_list, bugtrack_list では遅さが目立つ」がその記述になります。tracker_list 対象が1000ページあったとすると、ページリンクを生成するためにファイルシステムアクセスである is_page() と get_filetime() がそれぞれ最低1000回呼び出され、これが遅いということでした。実装をpushしました commit:3e9aff6511 -- umorigu
- 原因はページリンク(経過表示のためのファイル更新日時取得)が多いことであることがわかりましたので、対策自体は個別のプラグイン側で行います。チケットとしては原因判明で完了にします -- umorigu