56

Ubuntu Server 12.04（64ビット）VM（VirtualBox）でSymfony2を実行しています。ホストはMacBookProです。何らかの理由で、開発モード（app_dev.php）で非常に長いリクエスト時間が発生しています。開発モードでは遅いことはわかっていますが、リクエストごとに5〜7秒話します（場合によってはさらに遅くなります）。私のMacでは、開発モードで200ms程度のリクエスト時間があります。

Symfony2プロファイラーで私のタイムラインを見た後、リクエスト時間の約95％が「初期化時間」であることに気づきました。これは何ですか？それがとても遅いかもしれないいくつかの理由は何ですか？

この問題は、開発モードのSymfony2にのみ適用され、VMで実行している他のサイトには適用されず、本番モードのSymfony2にも適用されません。

私はこれを見ました（http://stackoverflow.com/questions/11162429/whats-included-in-the-initialization-time-in-the-symfony2-web-profiler）が、私の質問に答えていないようです。

4

9 に答える 9

127

デフォルトでSymfony2から5-30秒の応答がありました。現在、開発環境では約500ミリ秒です。

次に、次のことを変更しましたphp.ini。

  • セットrealpath_cache_size = 4M（またはそれ以上）
  • 完全に無効になっていますXDebug（でテストphpinfo）
  • realpath_cache_ttl = 7200
  • 有効にしてOPcache正しく設定（またはAPC）
  • php.iniをリロードするためにApacheを再起動しました

そして、voilá、応答は開発モードで2秒未満になりました！それが役に立てば幸い。

前： 6779ミリ秒 ここに画像の説明を入力してください

後： 1587ミリ秒

ここに画像の説明を入力してください

Symfony2は何千ものファイルからクラスを読み取りますが、それは遅いプロセスです。小さなPHPリアルパスキャッシュを使用する場合、ファイルパスがPHPのリアルパスキャッシュにない場合は、開発環境で新しいリクエストが行われるたびにファイルパスを1つずつ解決する必要があります。Symfony2のデフォルトでは、リアルパスキャッシュは小さすぎます。もちろん、これは問題ではありません。

キャッシュメタデータ：

メタデータ（マッピングなど）をキャッシュすることも、パフォーマンスをさらに向上させるために非常に重要です。

doctrine:
    orm:
        entity_managers:
            default:
                metadata_cache_driver: apc
                query_cache_driver: apc
                result_cache_driver: apc

これを有効にする必要がありますAPCu。すでにオペコードキャッシングが行っているAPCように、バイトコードキャッシュはありません。PHP5.5以降に組み込まれています。OPCacheOPCache

----後： 467ミリ秒----

（本番環境では、同じ応答は約80ミリ秒です）

ここに画像の説明を入力してください

これは30以上のバンドルを使用するプロジェクトであり、数万行のコードとほぼ100の独自のサービスがあるため、いくつかの簡単な最適化を使用するローカルWindows環境では0.5sが非常に適していることに注意してください。

于 2013-07-29T00:54:45.230 に答える
15

私は問題の原因を突き止めました（そしてそれはSymfony2ではありません）。何らかの理由でubuntuVMで、特定のファイルの変更時刻が正しくありません（つまり、将来など）。symfony2がfilemtime（）を使用してこれらの時間をレジストリと照合すると、キャッシュが新しくなくなったと判断し、すべてを再構築します。なぜそうなっているのか、まだわかりません。

于 2012-10-19T04:04:52.590 に答える
4

xdebug (v2.2.21)また、MacBookでのapache2の最大タイムアウトの読み込みをデバッグするために無効にする必要がありました。macportsを使用してインストールされました：

sudo port install php54-xdebug.

xdebugを有効にすると、すべてのページで最大読み込み時間がなくなり、最大タイムアウトメッセージを超える致命的なエラーが送信されます。無効にすると、すべてが妥当な予想時間内に正常にロードされます。私はMAMPを使用してこれに到達しましたが、デフォルトではxdebugは有効になっておらず、apache2は通常どおり高速に動作します。以前はxdebugが正常に機能していたため、別のデバッガーに変更する可能性があります。

構成：

  • MacOSX 10.6.8
  • macports 2.1.3
  • Apache 2.2.24
  • php 5.4
于 2013-03-12T14:54:57.160 に答える
4

同じ問題があります。ここでは、すべてのリクエストに対して10秒以上あります。bootstrap.php.cacheの次の行を削除すると、常に通常の状態（298ミリ秒）に戻ります。

foreach ($meta as $resource) { 
if (!$resource->isFresh($time)) {
return false;
}
}

変更時刻が間違っている可能性がありますが、修正方法がわかりません。誰かが解決策を知っていますか？

于 2015-05-07T08:30:50.970 に答える
2

https://stackoverflow.com/a/12967229/6108843で述べたように、そのような動作の理由はUbuntuVM設定である可能性があります。https://superuser.com/questions/463106/virtualbox-how-to-sync-host-and-guest-timeで説明されているように、ホストOSとゲストOSの間で日付と時刻を同期する必要があります。

FTP経由でVMにファイルをアップロードすると、ファイルの変更日がホストの値に変わります。そのため、filemtime（）は間違った値を返します。

于 2016-03-24T12:17:58.497 に答える
2

あなたは移動することができAPP/var/cacheます/dev/shm/YourAppName/var/cache。ただし、IDEのオートコンプリートとコード検証のために、ローカルファイルにもコンテナを構築しておくとよいでしょう。でapp/AppKernel.php：

public function getCacheDir()
{
    return $this->getVarOrShmDir('cache/' . $this->getEnvironment());
}

public function getLogDir()
{
    return $this->getVarOrShmDir('logs');
}

private function getVarOrShmDir($dir)
{
    $result = dirname(__DIR__) . '/var/' . $dir;

    if (
        in_array($this->environment, ['dev', 'test'], true) &&
        empty($_GET['warmup']) && // to force using real directory add ?warmup=1 to URL
        is_dir($result) && // first time create real directory, later use shm
        file_exists('/bin/mount') && shell_exec('mount | grep vboxsf') // only for VirtualBox
    ) {
        $result = '/dev/shm/' . 'YourAppName' . '/' . $dir . '/' . $this->getEnvironment();
    }

    return $result;
}
于 2016-05-21T08:54:07.937 に答える
1

xdebugを無効にすると、読み込み時間が17秒（はい..）から0.5秒に短縮されました。

于 2013-02-13T13:34:23.850 に答える
1

開発中のページの読み込みが遅いという問題もありました。これは、CSSなどを微調整しているときに非常にイライラする可能性があります。

少し掘り下げた後、私にとって問題は、ページの読み込みごとにすべてのアセットを再コンパイルしていたAsseticが原因であることがわかりました。

http://symfony.com/doc/current/cookbook/assetic/asset_management.html#dumping-asset-files-in-the-dev-environment

Asseticコントローラーの使用を無効にすることで、ページの読み込みを大幅に増やすことができました。ただし、上記のリンクに示されているように、アセットに変更を加える（またはウォッチを設定する）たびに、アセットを再生成するというコストがかかります。

于 2014-10-07T02:53:49.117 に答える
-2

app_devでは、すべてのキャッシュと自動読み込みが最初から開始されており、devで最も遅いことがわかったのはormです。私はormの使用を躊躇し、それが原因で主にdbalに焦点を合わせていますが、おそらくそうすべきではありません。Ormはsf2でかなり使用されています。私の推測では、ormは開発で最も遅くなっているものです。devconfigとprodconfigの違いを見てください。ただし、開発構成を微調整することで、開発をより迅速で楽しいものにすることができます。たとえば、小枝コントローラーをオフにしてから、多くのテンプレートを変更するのは、ちょっとイライラします。キャッシュをクリアし続ける必要があります。しかし、あなたが言ったように、その開発者だけが、そしてライブになる時が来たとき、symfonyはあなたのためにスピードアップします。

于 2012-10-16T02:02:28.587 に答える