| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346 |
- <?xml version="1.0" encoding="UTF-8"?>
- <!-- Reviewed: no -->
- <!-- EN-Revision: 24249 -->
- <sect1 id="performance.classloading">
- <title>クラスの読み込み</title>
- <para>
- Zend Frameworkアプリケーションのプロファイルをとってみた人は誰でも、
- Zend Frameworkではクラスの読み込みが比較的高くつくことにすぐ気がつくでしょう。
- 多くのコンポーネントのために読み込まれる必要があるクラスファイルの本当の数、
- クラス名とファイルシステムとの間に1対1の関係が成立しないプラグインの利用、
- <methodname>include_once()</methodname> や <methodname>require_once()</methodname> などの呼び出し、
- これらの間には検討の余地があり得ます。
- この章ではこれらの問題に対して確立したいくつかの解決方法を提示するつもりです。
- </para>
- <sect2 id="performance.classloading.includepath">
- <title>どのようにしたらinclude_pathを最適化できますか?</title>
- <para>
- クラスの読み込み速度を向上させるためにできる、
- ささやかな最適化のひとつはinclude_pathに注意をはらうことです。
- 特に4つのことをすべきでしょう:
- 絶対パスを使うこと(または相対パスを絶対パスに変えること)、
- 定義したincludeパスの数を減らすこと、
- include_pathにZend Frameworkをできる限り先に設定すること、
- そして現行ディレクトリパスをinclude_pathの最後にだけincludeすることです。
- </para>
- <sect3 id="performance.classloading.includepath.abspath">
- <title>絶対パスを使う</title>
- <para>
- これは些細な最適化に見えますが、
- 実は、やらなければ<acronym>PHP</acronym>のrealpathキャッシュの恩恵がほとんど受けられません。
- 結果として、あなたが期待するようにはopcodeキャッシュもほとんど動作しません。
- </para>
- <para>
- このことを確かめる易しい方法が2つあります。
- ひとつはパスを<filename>php.ini</filename>や<filename>httpd.conf</filename>、
- もしくは <filename>.htaccess</filename>でハードコーディングすることです。
- もうひとつは<acronym>PHP</acronym>の <methodname>realpath()</methodname>
- 関数を使ってinclude_pathを設定することです:
- </para>
- <programlisting language="php"><![CDATA[
- $paths = array(
- realpath(dirname(__FILE__) . '/../library'),
- '.',
- );
- set_include_path(implode(PATH_SEPARATOR, $paths);
- ]]></programlisting>
- <para>
- とある絶対パスとの関連性がある限り、
- 相対パスを使用することが<emphasis>できます</emphasis>。
- </para>
- <programlisting language="php"><![CDATA[
- define('APPLICATION_PATH', realpath(dirname(__FILE__)));
- $paths = array(
- APPLICATION_PATH . '/../library'),
- '.',
- );
- set_include_path(implode(PATH_SEPARATOR, $paths);
- ]]></programlisting>
- <para>
- しかしながらそうであっても、
- <methodname>realpath()</methodname> にパスを単純に渡すことが一般的にありふれたやり方でしょう。
- </para>
- </sect3>
- <sect3 id="performance.classloading.includepath.reduce">
- <title>定義したincludeパスの数を減らす</title>
- <para>
- includeパスはinclude_pathに記載された順番にスキャンされます。
- ファイルが後からではなく最初のほうのスキャンで見つかれば、
- 結果を早く得られることをこのことは明らかに意味します。
- 従って、やや分かりやすい高速化方法は、
- include_path上のパスの数を必要とするものだけに単純に減らすことです。
- 定義したinclude_pathそれぞれを精査して、
- アプリケーションで使われるパスに何らかの機能が実際にあるのか判断してください。
- もし無いのであれば削除してください。
- </para>
- <para>
- 他の最適化にはパスの合併があります。
- 例えば、Zend Frameworkは<acronym>PEAR</acronym>の命名規則に従っています。
- そのため、もし<acronym>PEARの</acronym>ライブラリを使うなら、
- (または<acronym>PEARの</acronym>命名規則に従うほかのフレームワークやライブラリを使うなら)
- それらすべてのライブラリを同じinclude_pathに入れてみてください。
- 1つ以上のライブラリを共通のディレクトリにsymlinkでまとめるのと同じくらい簡単に、
- しばしば目標に達することができます。
- </para>
- </sect3>
- <sect3 id="performance.classloading.includepath.early">
- <title>Zend Frameworkのinclude_pathを出来るだけ先に定義する</title>
- <para>
- 前述の提案に引き続き、
- Zend Frameworkのパスをinclude_pathの中でできる限り先に定義することも明らかな別の最適化です。
- 多くの場合、そのリストの中の一番最初のパスになるでしょう。
- このことにより、
- Zend Frameworkからincludeされるファイルが最初のスキャンで見つかることを保証します。
- </para>
- </sect3>
- <sect3 id="performance.classloading.includepath.currentdir">
- <title>現行ディレクトリは最後に定義するか、または定義しない</title>
- <para>
- ほとんどの例でinclude_pathに現行ディレクトリ、つまり '.' が見受けられます。
- スクリプトを必要とするファイルとしては、
- 同じディレクトリにあるスクリプトを確実に読み込めるので便利です。
- しかしながら同じくそれらの例では、
- 現行ディレクトリが一般的にinclude_pathの最初の要素として見つかります。
- このことは現行ディレクトリの配下がいつも最初にスキャンされることを意味しています。
- Zend Frameworkアプリケーションでは多くの場合望ましくありません。
- 間違いなく現行ディレクトリはリストの最後の要素に入れても良いでしょう。
- </para>
- <example id="performance.classloading.includepath.example">
- <title>例: 最適化されたinclude_path</title>
- <para>
- それではこれらすべての提案を一緒に実施してみましょう。
- 仮にZend Frameworkと一緒にひとつ以上の<acronym>PEAR</acronym>
- ライブラリを使っていると仮定します。
- ひっとするとPHPUnitや<classname>Archive_Tar</classname>ライブラリかもしれませんし、
- 場合によっては現行のファイルに関連してincludeする必要のあるファイルかもしれません。
- </para>
- <para>
- 初めに、プロジェクト内にライブラリのディレクトリを作成します。
- ディレクトリの中にはZend Frameworkの <filename>library/Zend</filename>
- ディレクトリをsymlinkで設定し、
- 同様にインストールした<acronym>PEAR</acronym>から必要なディレクトリを設定します。
- </para>
- <programlisting language="php"><![CDATA[
- library
- Archive/
- PEAR/
- PHPUnit/
- Zend/
- ]]></programlisting>
- <para>
- これで必要に応じて共有ライブラリをそのままに保ちながら、
- 独自のライブラリのコードを追加できるようになります。
- </para>
- <para>
- 次に <filename>public/index.php</filename> ファイルで予定通りinclude_pathを作成します。
- これでinclude_pathを毎回編集しなくても、
- コードをファイルシステム内で移動させることができます。
- </para>
- <para>
- それぞれの提案のアイデアは上記から取り入れています。:
- 絶対パスを使います。<methodname>realpath()</methodname> を使う判断がされています。;
- include_pathの先のほうでZend Frameworkをincludeします。;
- さらにまたinclude_pathを併合します。;
- そして現行ディレクトリをパスの最後にします。
- 思い切って本当にうまくするとこのようになります。
- 結果としてパス2つだけに到達します。
- </para>
- <programlisting language="php"><![CDATA[
- $paths = array(
- realpath(dirname(__FILE__) . '/../library'),
- '.'
- );
- set_include_path(implode(PATH_SEPARATOR, $paths));
- ]]></programlisting>
- </example>
- </sect3>
- </sect2>
- <sect2 id="performance.classloading.striprequires">
- <title>どのようにしたら不要なrequire_once文を除去できますか?</title>
- <para>
- Lazy loadingとは、
- 高くつくクラスファイルの読み込み操作をできるだけ最後の時にさせるように構想された最適化技術です。
- つまり、クラスのオブジェクトのインスタンス化、
- 静的なクラスメソッドの呼び出し、
- あるいはクラスの定数や静的プロパティを参照するときです。
- これは<acronym>PHP</acronym>ではオートローディングを通じてサポートされます。
- それにより、
- クラス名をファイルに紐付けるために実行するひとつ以上のcallback関数を定義できます。
- </para>
- <para>
- しかしながら、
- ライブラリのコードがまだ<methodname>require_once()</methodname>呼び出しを行なっているなら、
- オートローディングから受け取るであろう利益のほとんどは失われます。
- Zend Frameworkの場合もまさにその通りです。
- そこで質問があります:
- オートローダーの性能を最大化するために、
- それらの<methodname>require_once()</methodname>呼び出しをどのようにしたら除去できるでしょう?
- </para>
- <sect3 id="performance.classloading.striprequires.sed">
- <title>findおよびsedコマンドを使ってrequire_onceの呼び出しを取り去る</title>
- <para>
- <methodname>require_once()</methodname>呼び出しを除去する簡単な方法は、
- <acronym>UNIX</acronym>のユーティリテイーのfindとsedコマンドを組み合わせて、
- 各呼び出し箇所をコメントアウトすることです。
- 下記の命令を試しに実行してみてください。
- ('%'記号はシェルプロンプトを示します):
- </para>
- <programlisting language="shell"><![CDATA[
- % cd path/to/ZendFramework/library
- % find . -name '*.php' -not -wholename '*/Loader/Autoloader.php' \
- -not -wholename '*/Application.php' -print0 | \
- xargs -0 sed --regexp-extended --in-place 's/(require_once)/\/\/ \1/g'
- ]]></programlisting>
- <para>
- (読みやすくするために2行に分けていますが)
- この一行コマンドは各<acronym>PHP</acronym>ファイルを繰り返し処理しながら、
- 'require_once' を '// require_once' で置換し、
- 効果的にその命令をコメントアウトします
- (<classname>Zend_Application</classname> と
- <classname>Zend_Loader_Autoloader</classname> の中にある
- <methodname>require_once</methodname> はそのままにしてあります。
- そうしないと処理が失敗するからです)。
- </para>
- <para>
- 製品のアプリケーションの性能向上を助けるために、
- このコマンドは自動化されたビルドやリリース工程にささやかに付け加えられます。
- しかしながら、もしこの技術を使う場合は、
- オートローディングを使わ<emphasis>なければいけない</emphasis>、
- ということを記載しておかなければいけません。;
- "<filename>public/index.php</filename>"ファイルで下記のコードを記述することにより実施できます。
- </para>
- <programlisting language="php"><![CDATA[
- require_once 'Zend/Loader/Autoloader.php';
- Zend_Loader_Autoloader::getInstance();
- ]]></programlisting>
- </sect3>
- </sect2>
- <sect2 id="performance.classloading.pluginloader">
- <title>どのようにしたらプラグインの読み込みを速く出来ますか?</title>
- <para>
- 多くのコンポーネントにはプラグインがあり、
- Zend Frameworkとともに出荷された既存の標準プラグインを上書きして、
- そのコンポーネントで利用する独自のクラスを作成できます。
- このことにより、さほどの犠牲を払わなくても、
- フレームワークに重要な柔軟性が得られます。:
- プラグインローディングはある程度高くつく作業です。
- </para>
- <para>
- プラグインローダーによりクラスのプレフィックスやパスのペアを登録したり、
- 標準的ではないパスでクラスファイルを指定できます。
- 各プレフィックスはそれに関連した複数のパスを持つことができます。
- 内部的にはプラグインローダーは各プレフィックスごとに繰り返して、
- 各パスをそれに追加し、ファイルが存在するかどうか、
- およびそのパスが読み込み可能かどうかをテストします。
- 読み込むと探しているクラスが利用可能かどうかテストします。
- そのためご想像の通り、
- ファイルシステム上で多数のstat呼び出しが引き起こされます。
- </para>
- <para>
- プラグインローダーを使うコンポーネントの数によってこれをどんどん増やしてください。
- そしてこの問題の範囲のアイデアが得られます。
- この文章を記載した時点では、下記のコンポーネントがプラグインローダーを使います。
- </para>
- <itemizedlist>
- <listitem><para>
- <classname>Zend_Controller_Action_HelperBroker</classname>: ヘルパ
- </para></listitem>
- <listitem><para>
- <classname>Zend_Dojo</classname>: ビューヘルパ、フォーム要素およびデコレータ
- </para></listitem>
- <listitem><para>
- <classname>Zend_File_Transfer</classname>: アダプタ
- </para></listitem>
- <listitem><para>
- <classname>Zend_Filter_Inflector</classname>: フィルタ
- (ViewRendererアクションヘルパおよび <classname>Zend_Layout</classname> に使用されます)
- </para></listitem>
- <listitem><para>
- <classname>Zend_Filter_Input</classname>: フィルタおよびバリデータ
- </para></listitem>
- <listitem><para>
- <classname>Zend_Form</classname>: 要素、バリデータ、フィルタ、
- デコレータ、キャプチャ、ファイル転送アダプタ
- </para></listitem>
- <listitem><para>
- <classname>Zend_Paginator</classname>: アダプタ
- </para></listitem>
- <listitem><para>
- <classname>Zend_View</classname>: ヘルパ、フィルタ
- </para></listitem>
- </itemizedlist>
- <para>
- どのようにしたらそのような生成された呼び出しの数を減らせますか?
- </para>
- <sect3
- id="performance.classloading.pluginloader.includefilecache">
- <title>ファイルキャッシュを含むプラグインローダーを使う</title>
- <para>
- Zend Frameworkの1.7.0でプラグインローダーにincludeファイルキャッシュが
- 追加されました。
- この機能は"<methodname>include_once()</methodname>"呼び出しをファイルに書き出します。
- そのファイルはブートストラップでincludeできます。
- これは追加の<methodname>include_once()</methodname>呼び出しをコードに導入しますが、
- またそのことはプラグインローダーができるだけ早く結果を戻すことを保証します。
- </para>
- <para>
- プラグインローダーのドキュメントに<link
- linkend="zend.loader.pluginloader.performance.example">
- その使い方の完全な例があります</link>。
- </para>
- </sect3>
- </sect2>
- </sect1>
- <!--
- vim:se ts=4 sw=4 et:
- -->
|