不要なライブラリを読み込まないようにする†
- 元タイトル: 不要なファイルを読み込まないようにする(高速化?)
- ページ: BugTrack2
- 投稿者: 0
- 優先順位: 低
- 状態: 却下
- カテゴリー: その他
- 投稿日: 2006-07-18 (火) 18:26:00
- バージョン:
メッセージ†
また微妙な提案です。
ごく一部の条件下でしか使用しないライブラリを毎回読み込むのを止めると、若干ですが軽くなるのではないかと思います。
手間と若干の速度を天秤にかけ、どちらを取るのかはお任せします。
以下に呼び出し箇所を書き出しました*1。前半部分は対処等を入れていますが、同じことの繰り返しになるので後半部分は省略しました。
- lib/backup.php
- 使用箇所-1 : lib/file.php -> page_write()
- 対処 : page_write() で require_once
- 使用箇所-2 : backup.inc.php
- 対処 : plugin_backup_init() で require_once
- その他 : lib/backup.php を必要とするプラグインの init で require_once
- lib/diff.php
- 使用箇所-1 : lib/file.php -> page_write()
- 対処 : page_write() で require_once
- 使用箇所-2 : backup.inc.php -> plugin_backup_action()
- 対処 : plugin_backup_init() で require_once
- その他 : lib/diff.php を必要とするプラグインの init で require_once
- 備考 : diff.inc.php では生成されたファイルにアクセスするだけなので、 diff.php は関係ない
- lib/config.php
- 使用箇所-1 : lib/func.php -> get_autolink_pattern()
- 使用箇所-2 : attach.inc.php
- 使用箇所-3 : refer.inc.php
- 使用箇所-4 : tracker.inc.php
- 使用箇所-5 : tracker_list.inc.php *2
- lib/mail.php
- 使用箇所-1 : lib/file.php -> file_write()
- 使用箇所-2 : attach.inc.php -> attach_upload()
- lib/link.php ($related_link = 0; の場合は使用されない)
- 使用箇所-1 : lib/file.php page_write()
- 使用箇所-2 : lib/html.php -> make_related() (make_related() >>> lib/file.php -> links_get_related() >>> lib/link.php -> links_get_related_db())
- $related_link = 1; だと make_related() が呼び出される。
- 使用箇所-3 : related.inc.php (make_related())
- 使用箇所-4 : links.inc.php (links_init())
- 使用箇所-5 : rename.inc.php (links_update())
今後、Config を使用する機会が増えるのであれば*3個別呼び出しは微妙ですが。
- お疲れ様です。減量ネタのようですね。 -- henoheno
- 不要なrequire/includeをカットするという点では、1.4.6 の頃に lib/trackback.php, lib/mail.php について整理を行いました。役割ごとにある程度ライブラリ化したこれらのファイルについて、それを絶対に使わない構成であっても、今までは必ず requre() していたからです。 -- henoheno
- こうした行為に性能的な意味があるのか、またrequire()/include()という言語構造がどの時点でどう動いて、Zend Encoder や eAccelerator などのコードキャッシュ製品にどう処理されるのかは、そういえば把握していませんね (^^; if文で囲む使い方は問題ない様ですし、各ライブラリファイルが絶対に必要ないシチュエーションであれば、各ファイルが無くても絶対に動作するようになりましたから、独立性という点で最低限の意味があるのですが。 -- henoheno
- lib/mail.php については、そもそも lib/pukiwiki.php 内で、ファイル本体を require() するかどうかが設定 $notify によってコントロールされており、attach.inc.php などでも同じ基準で判定されている中で関連関数が利用されていますから、既にこの件は実装済みであると考えます。 -- henoheno
- lib/config.php があんまり使われないという指摘に賛成です。この仕組みは大部分のプラグインでは利用されません。標準機能として使うのも色々と難があると思います。また、lib/backup.php や lib/diff.phpが特定のシチュエーションにしか使われない(例えば最も実行される cmd=read はこれらを使わない)という指摘も賛成です。 -- henoheno
- lib/confg.php については、ご指摘の通りにするのが適当ではないかと思っています。 -- henoheno
- lib/backup.php, lib/diff.php についてはもう少し大きく改築できると思います。今回の視点があるならば、それぞれのライブラリ(ということになっている)ファイルを無条件にロードしてしまっていたり、様々な処理を無条件に行ってしまっている lib/pukiwikii.php や lib/init.php にこそ最も大きな改善の余地がある、という事にならないでしょうか。 -- henoheno
- backup/diffの様なケースの場合は「ユーザーから与えられた雑多なリクエストをそれぞれ最短で終わらせるためには何が必要か」をある程度明確にする事が求められていないでしょうか。極端な例を挙げると、アクセスが認められないホストからのアクセス*4や、明らかに異常な内容のリクエストや、特定のファイルが更新されていないかどうかを HTTP HEAD メソッドで確認する事だけが目的であるリクエスト*5については、条件さえ合うのであれば大部分の処理が不要になるはずです -- henoheno
- そして実際に、ユーザーから与えられた雑多なリクエストの処理を開始するこの lib/pukiwiki.php や lib/init.php は、現状「個々のリクエストについて、求められる必要最小限の動作を行う」様にできていないはずです(私はそう思います)。 -- henoheno
- 何にせよ、大事な話題だと思います。 -- henoheno
- うぉ! すごい情報量ですね。コードキャッシュ製品については全く考えていませんでした。 -- 0
コードキャッシュ製品 (以下、CC製品) とrequire/includeについて†
- コードキャッシュ製品(以下、CC製品)について。CC製品には触れた事がなかったのですが、この機会に eAccelerator を試験導入してみました。 -- 0
- (既知かも知れませんが)ファイル単位でキャッシュされ、キャッシュの存在しないファイルを require と当該ファイルが新たにキャッシュされる*6ようです。軽くテストした程度で、しかも全く論拠はありませんが、中間コードの保持･読込では、CC製品にバグがなければ大丈夫な気がします。 -- 0
- 何にせよ、今回使用したCC製品及びバージョン又はテスト環境以外については何とも言えません。という事で基本的にCC製品については口出しできません (^^; -- 0
lib/trackback.php と lib/mail.php†
- lib/trackback.php と lib/mail.php の違いを挙げると以下のようになります。 -- 0
- lib/trackback.php は cmd=read 時にも $body に追加される*7ので、閲覧負荷の点では現状のままでも変わりありません。 -- 0
- もし手を加えるのであれば、lib/trackback.php が必要とされる状況*8でのみ読み込むようにするくらいですかね。cmd=xxx (read 又は trackback 以外) では必要ないかと。 -- 0
- lib/mail.php は更新又は添付時のみ必要であり、cmd=read 時には必要ありません。よって必ずしも pukiwiki.ini.php で設定した $notify が最適とは限りません。(POST 時以外は読み込むべきではないかも知れません) -- 0
lib/pukiwiki.php と lib/init.php について†
- lib/pukiwiki.php と lib/init.php(二つ併せて、以下 ココ) について。現状の lib/pukiwiki.php ではほとんどのライブラリを読み込んだ後に lib/init.php で初期化処理を行なっているので、無駄が出来やすいのだと思います。初期化に必要なライブラリが読み込まれた時点で初期化処理を始めるようにすれば現状より無駄がないかと思います。ただ、ライブラリとプラグイン及びページとプラグインの依存関係をココだけで処理するのには限界があるので、どれだけの処理を任せるのが最適かの判断は難しいところです。 -- 0
- 例えば、プラグインのインストールという概念(hikiで言えば、ディレクトリ内に存在していても有効/無効を設定できる)を用いるのであれば、ライブラリとプラグインの依存関係は把握可能です*9。しかし、この方法では、ページとプラグインの依存関係は把握不可能です。 -- 0
- lib/init.php で各プラグインを決め打ちする*10のであれば、ある程度詳細に出来るかも知れませんが、未知のプラグインに対応するには不十分です。lib/init.php ではGET/POST のどちらかによって処理を変える*11程度又は HTTP HEAD の確認時のような特殊な処理の振り分けが限界ではないでしょうか。 -- 0
- ココで、log(以下に書きます) の概念を用いるとし、完璧なパースができるのであれば話は別ですが。 -- 0
- なんだろう。もっと簡単な解決法があるかな･･･。 -- 0
HTTP HEAD について／ブラウザの挙動について (If-Modified-Since)†
（BugTrack/799#hf6aafecに移動）
fabicon.ico について†
- あ、ここで良いのか分かりませんが、読み込みついでに favicon について。スキンで favicon の設定をデフォルトにしていた場合、<head> に <link rel="SHORTCUT ICON" href="" /> のように出力されますが、空の場合は出力しないようにした方が良いかと思います。 -- 0
- (fx 1.5.0.4 で)通常の閲覧では favicon.ico を探しに行きますが、POST 処理(編集 -> ページの更新)ではなぜか index.php を読みにいきます。 -- 0
- あ･･･。$related_link = 0; の場合、lib/link.php も必要ありませんね。1 でも links_get_related_db($page) 以外は POST 時にしか必要なさそうですね。 -- 0
- POST 時にしか使用されないものは読み込めないように分離しても良いかも知れませんね。lib/file.php は POST 時以外には使用しないほうが良さそうな関数がたくさんありますし。 -- 0
コメント†
- とある PukiWiki 設置サーバーが負荷で悲鳴をあげているので、細かいところが気になってしまいます。ごめんなさい、すごく長くなりましたがとりあえず以上(のはず)です。 -- 0
- 情報ごとに見出しと #comment を追加し、先頭に #contents を追加しました。こうした整理も各自でやっていただけるとありがたく (^^; -- henoheno
- 日頃あちこちの事例を見て回っているので、何か運用の問題が発生している所についてはいつも気にしています。これで「いきいきWiki」の人たちは目次に対するリンクが変化しなくなるので、今までの様に苦労しなくていいはずだとか、これで「 人狼BBS まとめサイト」に同様な負荷の問題が起きたときでも(話題になった点については)解消されるはずだ、とか、リリースが終わる度に思うものです :) なにか大きな話題があるなら、ぜひ我々にも事例そのものを教えて下さい。個人メールでもいいですけど。 -- henoheno
- 当方でも必要に迫られてlib/backup.phpの修正を行い、改善されました。少しずつでも次期リリースから反映されることを希望します。 -- よっちい
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
