0

requestAction主に、CakePHP で何かをレンダリングするために使用され、アプリケーションのすべてのページまたは最初に見つからなかった場所にある必要があります。

例: Web サイトの各ページのフッターに登録ユーザーの総数を表示する。

requestAction アプローチでは、モデル User のカウントを返す UsersController のアクションをリクエストすることでこれを行うことができます。usersCount() という名前にしましょう。このリクエストは、このアプリケーションのビューで使用されるレイアウトにある必要があります。

私が提案するアプローチでは、AppControler で User モデルを使用し、ユーザー数の変数を設定して、すべてのレイアウトとビューで使用できるようにする必要があります。たとえば、

//in AppController

function beforeRender(){
  $this->uses = array('Model', 'User');
  $this->set('totalUsers',$this->User->find('count'));
}

したがって、任意のレイアウト、ビュー、または要素で、 $totalUsers 値を簡単に使用できます

<div class="footer">Currently, we have <?php echo $totalUsers;?> registered users.</div>

ここでのより良いという言葉は、パフォーマンスを意味します。この2つのアプローチのどちらがパフォーマンスが優れていますか?

4

1 に答える 1

2

プロフィール

いくつかの可能性の相対的なパフォーマンスについて疑問がある場合は、他の人のアドバイス (純粋な憶測である可能性があります) に頼らないでください: profile。

DebugKitには、ベンチマーク情報を生成する便利な手段であるBenchmarkシェルが付属しています ( seigeとabは、より正確で信頼性の高い代替手段の 2 つです)。

$ cd my/app
$ Console/cake DebugKit.benchmark
Allows you to obtain some rough benchmarking statistics about a fully
qualified URL.

Usage:
cake debug_kit.benchmark [-h] [-v] [-q] [--n 10] [--t 100] <url>

Options:

--help, -h     Display this help.
--verbose, -v  Enable verbose output.
--quiet, -q    Enable quiet output.
--n            Number of iterations to perform. (default:
            10)
--t            Maximum total time for all iterations, in seconds.If a
            single iteration takes more than the tiemout, only one request will be
            made (default: 100)

Arguments:

url  The URL to request.

Example Use: `cake benchmark --n 10 --t 100 http://localhost/testsite`.
Note: this benchmark does not include browser render times.

このようなツールを使用すると、パフォーマンスに関するほとんどの疑問が解決されます。いくつかのコントローラー アクションを設定し、それぞれの相対的なパフォーマンスを記録するだけです。

なぜ2つの可能性に限定するのですか？

requestAction を使用することが、使用されない可能性のある変数を常に入力するよりも優れているかどうか (ヒント) ではなく、代わりに、すべて/ほとんどのページに <something> を表示する最良の方法は何ですか?

おそらくほとんどの問題に対処できる 2 つの簡単なルールを次に示します。

  1. キャッシュを使用する
  2. 使用しないデータを要求しない/使用する場合にのみデータを要求する

提案された 2 つのオプションのうち、requestActionいくつかの点ではより適切ですが、与えられた例と同じ結果を達成するための他のオプションがあります。

要素のキャッシング

常に (何らかの方法で) データを取得するのではなく、一度取得すると、データが古くなるまで取得しません。たとえば、レイアウトでは要素のキャッシュを使用して、要素に含まれるものがすべてのリクエストで実行されないようにします。

echo $this->element(
    'footer',
    array(),
    "cache" => array('config' => 'element_config', 'key' => 'footer')
);

要素の内容は、footer自己完結型である必要があります。たとえば、次のようになります。

<?php
$User = ClassRegistry::init('User');
// $betterExample = $User->expensiveCall(); // more relevant where the call is slow
$totalUsers = $User->find('count');
?>
<div class="footer">Currently, we have <?php echo $totalUsers;?> registered users.</div>

このように、要素のデータは、キャッシュされた結果がない場合にのみ要求されます。関連するキャッシュ構成を調整することにより(適切なキャッシュ構成は要件によって異なります。多かれ少なかれリアルタイムである必要があります。たとえば、30 秒のキャッシュ構成を使用します。古いかどうかは問題ではありません。1 日を使用します)。更新は変更できます。

または、無限のキャッシュ時間を使用することもできます。代わりに、値が変更された場合にのみキャッシュがクリアされます。

class User extends AppModel {

    public function updateCounterCache($keys = array(), $created = false) {
        Cache::delete('footer', 'element_config');
        return parent::updateCounterCache($keys, $created);
    }
}

他のテクニック？

使用できる他の同様の手法があります ( と組み合わせて要素を使用することを含むrequestAction) - ただし、原則は常に同じです: 必要のない可能性のあるロジックを熱心に実行 (データを取得) しないで、キャッシュを効果的に使用します。

于 2013-10-26T19:07:34.283 に答える