2016-04-14 4 views
-1

私は古いPHPフレームワークを書き直しています。現在、ナビゲーション、ルーティング、および認可は、各ページ要求でロードされる構成ファイルに基づいて行われます。さまざまなユーザーレベルのページルーティングとナビゲーションを保存するための最善のアプローチ

構成ファイルをデータベースに変更しました。読み込まれるページの数は、ユーザーレベルと承認に基づいてユーザーごとに異なります。 しかし、依然として各ページリクエストで複数のデータベースクエリが実行され、すべてのエントリがロードされ、ナビゲーション、ルーティング、および認証が処理されます。 ほとんどの場合、これらの機能の結果が特定のユーザーにとって同じであるため、これは「キャッシュされる」と思います。

最良のアプローチは何ですか?

オブジェクト内の関数の結果をキャッシュし、それらをセッションに格納しますか? 各ユーザーのオブジェクトで一時ファイルを生成しますか? Memcachedを使ってそれらをメモリに保存しますか? このようにして、各ページリクエストで処理しますか?

編集: フレームワークはOOP指向で、セッションオブジェクトのusername/userlevelのようなものをキャッシュしています。

答えて

1

機能の集まりでもOOP指向でも、フレームワークの仕組みが分からないので、正確な方向を指すのは簡単ではありませんが、繰り返しクエリを実行しないようにするためのアプローチがあります1回のリクエストで常に同じデータを返します。

のはあなたがログに記録された利用者の情報を必要とするあなたのアプリでいくつかの場所があるとしましょう、と簡略化のために、私はあなたのユーザーがオブジェクトであり、その認証は、クラスを使用して行われることを前提としています:)

上記の例では

class Auth 
{ 

    private static $logged_user = false; 

    static function getLoggedUser() 
    { 
    if (self::$logged_user === false) { 
     self::$logged_user = do_some_magic_(); 
    } 

    return self::$logged_user; 
    } 

} 
、私有財産 $logged_userがデフォルト falseであるかどうかをチェックします Auth::getLoggedUser()を呼び出し、それが続いているならば、それはauthenicationを実行します(たとえば、セッションまたは任意のデータを使用して)、そのプライベートクラスのプロパティにそれを格納し、 Auth::getLoggedUser()を連続して呼び出すたびに、すでにフェッチされたユーザーのオブジェクトが返されます。ログイン時に logged_userを設定することもできます。

同様の方法で、複雑な操作のさまざまな他の結果を「キャッシュ」し、時間/メモリ/クエリを節約できます。ただし、結果として得られたオブジェクトが実際にアプリケーションの要求中に変更された場合、望ましくない結果になる可能性があるので注意してください。

+0

ありがとうございました。私はフレームワークがOOPであることを明確にするために質問を編集し、あなたの答えにあなたが言及したものをキャッシュしています。 「(セッションなどのデータを使用しているなど)」と言う。それは私のポイントです:-)私はセッションからすべてを得るべきですか? Username/userlevelなどはすでにセッションに入っています。しかし、ナビゲーションの目的で階層構造を持つ '$ availablePages'、すべてのページにロードされたテンプレートファイルなどは、各ページリクエストで取得されます。このデータをセッションにも格納する必要がありますか?または、毎回これらのデータを取得するためのクエリを実行しますか? –

+0

ナビゲーションヒントを取得するのが複雑で、何度かアクセスしているのであれば(それは一度だけ行う必要がありますか?)、次にキャッシュしてください。ロールの「キャッシュファイル」に保存してそのまま再利用することもできますが、ロールが変更されたときにキャッシュを無効にすることに注意してください。一般的に言えば、応答時間やメモリ消費量が膨らんでいない場合は、パフォーマンスにほとんど影響を与えないものを過度に最適化しないでください。 –

+0

ありがとう、過最適化はおそらく私がやっていることの良い定義です。私はそれぞれのページの負荷の要求に固執します。 Thnx! –