0

次のシナリオのどれが最も効果的かを判断するのを手伝ってくれませんか。

3つのユーザーコントロールがあります。各コントロールは、SQL Serverクエリの結果に基づいてコンテンツを生成する必要があります。たとえば、ユーザーコントロール#1は、グリッドビューにクエリの出力を入力します。

SQL Serverデータベースへのラウンドトリップを減らすために、キャッシュを利用したいと思います。私は次の2つの解決策を思いつきましたが、どちらが最も効果的か知りたいです。

シナリオ#1:

3つのユーザーコントロールのクエリすべてを単一のSQLServerストアドプロシージャ(バッチ処理)に配置し、含まれているページ内のユーザーコントロールの外部でストアドプロシージャを実行してから、各ユーザーコントロールにクエリ出力を提供します。3つのクエリすべてを単一のストアドプロシージャに配置することで、データベースへのラウンドトリップが削減されます。
このシナリオでのキャッシュは、ストアドプロシージャの出力をキャッシュすることによって行われます。したがって、ストアドプロシージャの出力は、各ユーザーコントロールにその出力を提供するために毎回メモリから取得され、その後、各ユーザーコントロールがその出力を生成します。クエリの約188の異なるバージョンが、ASP.NETオブジェクトキャッシングによってキャッシュされます。

シナリオ#2:

各ユーザーコントロール内でSQLServerデータベースを個別にクエリし、それぞれが取得したクエリ結果を使用して各ユーザーコントロールの出力を生成します。これは、各ユーザーコントロールが個別にSQLServerデータベースを呼び出すことを意味します。このシナリオでのキャッシュは、各ユーザーコントロールの出力をキャッシュすることによって行われます。したがって、ユーザーコントロールは毎回出力を生成する必要がなく、メモリから直接出力を取得できます。このシナリオの落とし穴は、1つ以上のユーザーコントロールの約188の異なるバージョンをキャッシュする必要があることです。

前もって感謝します

4

2 に答える 2

1

いずれにせよ、188バージョンのデータをキャッシュする必要があります。私の投票は次のようになります:出力キャッシング-HTMLを生成するために必要な処理が少ないため(つまり、aspxページに含まれるため、結局のところ、最終的な目標です)、メモリ内でほぼ同じを達成するのに比べてキャッシュが実行されます(1人のユーザーが要求するたびにキャッシュされたデータをHTMLに変換する必要があるため、処理時間が長くなります。これは188回をはるかに超えます)。

出力キャッシュがどのように機能するか、およびリクエストURL(クエリ)に応じてさまざまなバージョンのHTMLをキャッシュする方法を明らかに理解しています。

于 2012-02-01T00:00:33.960 に答える
0

2つのシナリオが必ずしも相互に排他的であるとは思いません。必要に応じて、SQLクエリロジックを抽出して、コントロールで出力キャッシュを使用できない理由はありません。

繰り返しになりますが、実際には、データが変更される頻度と、データを最初に取得するのにかかる費用に基づいて、さらに大きく変化します。たとえば、(すべてのバージョンの)すべてのデータを取得してAppキャッシュに保持し、必要に応じてコントロールを生成するために1回のDB呼び出しを行うことができなかったという質問には何もありません。

于 2012-02-01T00:53:21.980 に答える