1

私たちのプロジェクトの 1 つを最適化する方法について、ちょっとしたアドバイスを探しています。SQL2008 データからデータを取得し、それを DevExpress ASPxGridView に表示する ASP.NET/C# システムがあります。検索されるデータは、多数のデータベースの 1 つから取得できます。データベースはすべてわずかに異なり、定期的に追加および削除されています。ユーザーにはライブの「会社」のリストが表示され、対応するデータベースからデータが取得されます。

現時点では、標準の SqlDataSource と動的に作成された SQL SELECT ステートメントを使用してデータを取得しています。ステートメントにはいくつかの JOIN と、オプションの WHERE 制約があり、データベースとユーザーの権限レベルに応じて動的に作成されます。

パフォーマンスは別として、これらはすべてうまく機能します (正直なところ!)。一部のデータベースに関しては、数十万の行があり、データの取得とページングが非常に遅くなります (データベースは既に適切にインデックス化されています)。したがって、私はシステムを高速化する方法を検討してきましたが、それは XPO または LINQ の 2 つの選択肢に要約されるようです。

LINQ は一般的な選択肢のようですが、本質的に非常に動的なシステムで実装するのがどれほど簡単かはわかりません.LINQ がアクセスできるデータベースごとに「定義」を作成する必要がありますか? また、LINQ クエリを動的に作成することについても少し確信が持てませんが、少なくともその一部が実行可能であるように思われるいくつかの例を見てください。

一方、XPO では、その場で XPO データ ソースを作成できるようです。ただし、他のテーブルに結合する方法に関する情報があまり見つかりません。

このプロジェクトにレトロフィットを試みるのに最適な方法 (ある場合) について、誰かアドバイスをいただけますか? それとも、現在使用されている動的 SQL モデルは LINQ や XPO とは根本的に異なり、そのままにしておくのが最善でしょうか?

4

3 に答える 3

2

私が理解している限りでは、すべてのデータ操作が Web サーバーに対して行われ、そこで処理されるのではなく、DB サーバー上で行われる、いわゆるサーバー モードについて話していると思います。このモードでは、グリッドは数十万のレコードを含むデータ ソースで非常に高速に動作します。このモードを使用する場合は、対応する LINQ クラスまたは XPO クラスを作成する必要があります。LINQ ベースのサーバー モードを使用する場合、LINQServerModeDataSource は、カスタム IQueryable および KeyExpression を設定するために使用できる Selecting イベントを提供します。アプリケーションで LINQ を使用することをお勧めします。この情報がお役に立てば幸いです。

于 2011-03-02T00:28:50.117 に答える
2

アプリがデータベースと対話する方法全体を変更する前に、次のことを確認しましたか。

  • コードをパフォーマンス プロファイラー (Redgate のパフォーマンス プロファイラーなど) で実行すると、多くの場合、驚くべき結果が得られます。

  • オンザフライで SQL 文字列を作成している場合、「str1」+「str2」ではなく String.Concat("str1", "str2") などの .Net ベスト プラクティスを使用していますか。複数の小さな利益が積み重なって大きな利益になることを忘れないでください。

  • 1 つのデータベースのみにアクセスできるように、定期的に (15 分ごとに、このデータを自動的に更新するサービスを実行する必要があるとします) 更新されるサマリー テーブルまたはデータベースを用意することを考えたことがありますか。データベースへの新しい接続は静かで高価です。

  • 実行している SQL のクエリ プランを確認しましたか。今日、動的に作成された SQL 文字列を sproc に移動し (1 つのパラメーターのみを変更)、実行時間を 5 ～ 10 秒短縮しました (条件によっては 100 ～ 10000 回呼び出されていました)。

LINQ を使用する場合の警告です。LINQ を使用することを決めた一部の開発者が、自分が何をしているのかを理解していなかったため、より非効率的なコードを記述しているのを見てきました (たとえば、1 をチェックする必要があるときに 36,000 レコードを取得するなど)。このことは非常に簡単に見落とされます。

あなたが始めるための何かであり、うまくいけば、あなたが考えていなかった何かがそこにあることを願っています.

乾杯、

ストゥ

于 2011-03-01T22:14:32.143 に答える
0

この場合、パフォーマンスを微調整できるポイントが 2 つあります。何らかの二次層を経由するのではなく、データベースに直接アクセスしていると仮定します。

まず、データ自体をどのように表示しているかを述べていません。何千ものレコードをグリッドにロードする場合、他のすべてがどれほど高速であっても時間がかかります。明らかに、ここでの秘訣は、データのサブセットを表示し、ユーザーがページングできるようにすることなどです。これを行っていない場合は、そこから始めるのがよいでしょう。

2 つ目は、テーブルが適切にインデックス化されているということです。この場合、一度に 1,000 レコードをページにロードせず、一度にサブセットのみを取得すると仮定すると、問題ありません。

しかし、ExecuteQuery()データセットを取得するために SQL 接続に対してのみ実行している場合、Linq や他のものがどのように役立つかわかりません。問題は明らかにDB側にあると思います。

したがって、データベースの問題を解決するには、データベースに対して実行しているさまざまな SELECT ステートメントをプロファイルし、クエリ プランを調べて、速度が低下している場所を特定する必要があります。SQL Server Profilerを使用して開始することもできますが、優秀な DBA がいる場合は、クエリ プラン (Management Studio から取得できます) を見るだけで十分な場合があります。

于 2011-03-01T22:23:58.837 に答える