6

Zend Framework 1.11、Doctrine 2、いくつかの Symfony 2 コンポーネント、およびその他のツールとライブラリを使用したプロジェクトに取り組んでいます。

Xdebug と Webgrind を使用してパフォーマンスを最適化しようとしています。

Ini configの解析などのボトルネックをすでに見つけており、それをキャッシュしました。

ここで、自動読み込みがアプリケーションの最もコストのかかる部分であることに気付きました。

    Opl\Autoloader\ApcLoader->loadClass                    274   31.36   43.86
    Zend_Loader_PluginLoader->load                         150    4.80   12.29
    Zend_Loader_Autoloader->getClassAutoloaders            278    1.42    1.91
    Zend_Controller_Router_Route_Regex->_getMappedValues   291    1.29    1.35
    Doctrine\ORM\UnitOfWork->createEntity                   85    1.24    3.18

ご覧のとおりZend_Loader_Autoloader、私はdefault を使用していません。Opl私が知る限り、それよりも速いものを使用してclassMapLoaderいます。

どうすればそれを最適化できますか?

私は約 250 個のクラスをロードしましたが、遅いのは 40 個までのようで、他のものは "Total call cost" として 0,00 を表示していますが、require 呼び出しで 0,08 から 0,57 に増加しているクラスもあります。

ちなみに、Opl オートローダーを使用しているため、私の実稼働環境の APC では、オートローダーによって呼び出されるファイルではなく、「手動で必要な」ファイルのみをオペコードがキャッシュしているように見えます。

4

4 に答える 4

4

コードのリファクタリングがオプションでない場合 (Zend Framework をドロップする、Doctrine をドロップする、ドロップするなど)、まず、より優れたハードウェアを購入することを最適化します。コードのコンテキストがシフトされるだけなので、コードが自動的に最適化されます (コードは変更されないため、これはコードを正確に最適化するわけではありません)。

それができない場合は、コードベースを前処理し、非開発バージョンを作成してロード プロセスを削減できるビルド システムを自分で作成することを検討してください。これには、常に必要なファイルを分析する必要があり、それらすべてを、単一ファイルおよび/または静的クラス ローダー マップであるローダー最適化形式にコンパイルします。

ただし、Zend は常に大量のデータをメモリにロードする必要があることが知られています。APC のような PHP キャッシュを使用しても、すでに何かが得られる場合があります (前述のビルド スクリプトを使用してプリコンパイルし、メトリックによって強調表示された部分を最適化することを検討してください)。

アプリケーションの構造が許せば、別の可能性もあります。リクエスト間でアプリケーション全体をメモリに保持します。これは、PHP Web サーバーで実行できます。これが完了すると、コードはサーバーの起動時にのみロードする必要があり、再度ロードする必要はありません。これは、複数のリクエストをサポートしている場合にのみ、独自のアプリケーションで機能します。特にリクエストロジックを備えた優れたカプセル化されたアプリケーションは、そのために非常に簡単に採用できます。既存のソリューションはappserver-in-phpです。すでに APC から得た利点と比較して、どれだけ速度が向上したかに驚かれることでしょう。

多分これは役に立ちました。コードの動作を確認したり、詳細なメトリックを表示したりすることができないため、追加のより具体的な提案を行うことは困難です。舞台裏で何が起こっているかについての断片を渡したばかりなので、より具体的に伝えるのは難しい.

于 2011-12-19T11:21:51.143 に答える
3

Xdebug と Webgrind を使用してパフォーマンスを最適化しようとしています

OK、あなたはより良いパフォーマンスを真剣に必要としている立場にあるので、あまり人気はありませんが、明らかに効果的な方法を受け入れるかもしれません。

Xdebug のように一時停止できるデバッガーがある限り、どの言語でも動作します。

ここでは簡単に説明します。 その有効性を示す 1 つのデモンストレーションを次に示します。 他にもたくさんリンクできます。

あなたはそれが少し知的に痛烈に感じるかもしれません. のように

  1. ルーチンに関連する時間として「ボトルネック」を見つけています。最も価値のある高速化の機会は、多くの場合、そのようには現れません。それらは、見れば簡単に説明できる活動ですが、散在しています。これらは、特定のルーチンやコード行に多くの時間を集中させないため、プロファイラーには表示されません。

  2. 最大のスピードアップの機会は、簡単に修正できない場合があります。プログラムの編成方法を再考する必要があるかもしれません。簡単に修正できるものを見つけたら、それは素晴らしいことです。さあ、やってみよう。それほど簡単に修正できない場合でも、多くの時間を節約できる場合、その時間を節約する必要がある場合は、好むと好まざるとにかかわらず、やらなければなりません。

幸運を。

于 2011-12-19T16:33:18.027 に答える
1

ハクレが提案していることは好きではありません。まず、Web サーバーを削除できるかどうかを調べます。その場合、良い代替手段は nginx または lighttpd です。今世紀のものである Apache と比較すると、構成もはるかに簡単です。オートローディングについてはよくわかりませんが、クラスファイルが非常に大きい場合は、RAM ディスクをインストールするか、php コンプレッサーを使用しようとしましたか? 私の経験では、PHP コンプレッサーを使用すると、実行時間 (つまり、解析時間) を大幅に短縮できます。

于 2011-12-19T13:04:54.917 に答える
0

私はあまり経験がありませんが、かつてそのような問題を抱えていました。インクルード パスを確認し、最大使用ライブラリ パスの順に並べ替えました。そして私はほぼ30％のブーストを得ました。私はそれがあなたによってすでに知られていると思いますが、何らかの方法で投稿しました........ :)

于 2012-07-07T14:28:45.173 に答える