1

Magentoには、定義されたパスのセットを介して予期されるファイルの存在をチェックすることにより、エラーやテーマの問題を防ぐのに役立つフォールバックメカニズムがあります。これは次のように実装されています

/**
 * Check for files existence by specified scheme
 *
 * If fallback enabled, the first found file will be returned. Otherwise the base package / default theme file,
 *   regardless of found or not.
 * If disabled, the lookup won't be performed to spare filesystem calls.
 *
 * @param string $file
 * @param array &$params
 * @param array $fallbackScheme
 * @return string
 */
protected function _fallback($file, array &$params, array $fallbackScheme = array(array()))
{
    if ($this->_shouldFallback) {
        foreach ($fallbackScheme as $try) {
            $params = array_merge($params, $try);
            $filename = $this->validateFile($file, $params);
            if ($filename) {
                return $filename;
            }
        }
        $params['_package'] = self::BASE_PACKAGE;
        $params['_theme']   = self::DEFAULT_THEME;
    }
    return $this->_renderFilename($file, $params);
}

Magentoテーマの開発者には、2つのオプションがあります。新しいテーマに追加するものをできるだけ少なくしてフォールバックに依存するか、フォールバックテーマからすべてを新しいテーマにコピーして変更することができます(この場合、フォールバックにはターゲットを見つける前に、より少ないファイルを反復処理します)。前者のアプローチをお勧めします。後者はそうではありません。

これらのファイルをコピーするのは確かに面倒ですが、一方で、フォールバックはかなり高価になるはずです。特に、(優れた、気の利いたコーダーであるため)できるだけ多くのファイルをフォールバックするようにしている場合はなおさらです。そのため、発生するフォールバックの量を最小限に抑えるための措置を講じた場合、Magentoサイトのパフォーマンスが向上するかどうか疑問に思います。

Webを検索しましたが、この質問に関する情報は見つかりませんでした。また、フォールバックを自分でプロファイリングするのに十分なMagentoに精通していません。このフォールバックメカニズムの実際のパフォーマンスコストに関する情報はありますか?

4

2 に答える 2

4

パフォーマンス コストは 37 です。

残念ながら、あなたの質問には答えられません。これらのファイルとディレクトリを記述することには (明らかに) パフォーマンス コストがかかりますが、Magento (およびすべての LAMP アプリケーション) は、他の要因よりもはるかに早く SQL オーバーヘッドと CPU によるパフォーマンスのボトルネックにぶつかります。最新の Web アプリケーションのパフォーマンス チューニングは、アプリケーション レベルで行われるのではなく、アプリケーションを変更不可能なブロブとして扱い、可能な限り最適なハードウェア セットアップを購入/構成する傾向があります。

フォールバックをオンまたはオフにして Magento のベンチマークを実施したことがある人は、情報を公開していません。

于 2012-01-11T17:00:53.750 に答える
0

パフォーマンス コストはかかりますが、Alan が言ったように、それはアプリケーションよりもサーバー アーキテクチャに依存します。

Magento にはコード ファイルのフォールバック メカニズムもあることに注意してください。テーマのフォールバックとは異なり、これには回避策があります。Magento はこれを「コンパイラ」と呼んでいます。

通常、クラスをロードする要求があると、オートローダーは適切な PHP ファイルを見つけるためにapp/code/localapp/code/communityapp/code/core、最後にlibの 4 つの場所を調べます。独自のバージョンで特定のコア コードをオーバーロードしたい場合に便利ですが、ファイル システムに散在する膨大な量のクラスのために速度が低下します。

そのため、Magento コンパイラは、オートローダーがincludes/srcのみを検索する必要があり、開くファイルが少なくなるようにします。

理論的には、サーバーはこれらのファイルをキャッシュする必要があるため、これは大きな違いはありませんが、記事全体を読んで、それほど単純ではない理由を理解する必要があります.

http://www.byte.nl/blog/should-i-use-the-magento-compiler

事例証拠: 多数のサードパーティ製モジュールを含むストアでは、コンパイルを有効にするだけで、最初のバイトまでの時間が ~2 秒から ~1.6 秒に短縮されました。

警告: 一部のサードパーティ モジュールは正しくビルドされておらず、コンパイルが有効になっているとストア全体が壊れる原因となります。通常、これは、相対パスを使用してファイルを取得しようとしていることが原因でinclude_onceありrequire_once、コンパイルが有効になっているときにファイルが別のディレクトリにあるため、機能しません。

于 2016-05-05T20:37:35.067 に答える