4

SSRSレポートを作成するとき、「可能な限り短い生成時間でレポートを作成する方法」について常にジレンマがあります。

一般に、生成時間（またはパフォーマンス時間）は2つの主要な部分に分けられます。

  1. SQLクエリ。
  2. レポートコンポーネント（式、グループなど）。

ご存知のように、SSRSで実行されていることのいくつかは、SQLクエリで実行でき、その逆も可能です。

例えば：

  • SQLで句を使用Group byできますが、グループ定義のあるテーブルを使用する場合も同じことができます。
  • CastingSQLと式の内部で2つの値を比較するために使用できます。

などなど...

私の質問は次のとおりです。

A.どの部分（SQLクエリまたはSSRS）がより多くの時間を要しますか（タスクがSSRSとSQLの両方で実行できると仮定して）？

B.与えられた状況をどこで実行するかというジレマを抱えているときに、私が決定の基礎とすべきガイドラインは何ですか？

4

2 に答える 2

6

いつものように、パフォーマンスの問題:

  • 時期尚早に最適化しないでください。SSRS で何かが簡単な場合は、そこで実行してください。問題が発生した場合にのみ、明快さとパフォーマンスのトレードオフを検討してください (コードを SQL 側に移動するなど)。
  • 測定。ExecutionLog2ビューを使用して、ボトルネックがどこにあるかについての一般的なアイデアを取得します。より多くの測定とテストを行って、重要なビットのパフォーマンスを改善するために時間を費やしていることを確認してください。

結論: 特定の問題を解決する場所を明確なコードで導き、パフォーマンスが問題になったときに選択的に最適化します。

Eric Lippert は、いつ、どのようにパフォーマンスを気にするべきかについて、すばらしいブログ記事を書きました。コンテキストは C# ですが、基本的な考え方は SSRS/SQL などの他の状況にも当てはまります。

ところで、前述のExecutionLog2ビューを見ると、パフォーマンスには実際に知っておくべき3 つの要素があることがわかります。

  1. データ取得 (SQL)
  2. レポート モデル (データセットを内部モデルに変換)
  3. レンダリング (モデルを XLS、PDF などに変換)

パフォーマンスの問題を解決する方法を知るには、ボトルネックがどの部分にあるかを知ることが重要です。

私の経験に基づいた提案で締めくくるには：

経験則として、特に集計のパフォーマンスが心配な場合は、SSRS よりも SQL をお勧めします。 必要に応じて、データベース (インデックスなど) のチューニングも検討してください。

この経験則は、事実と調査によって裏付けることができれば最適です。残念ながら、私は何も持っていません。私自身の経験では、ほとんどの場合、集計と計算を SSRS から SQL に移動するレポートでパフォーマンスの問題が発生したときに、この問題の解決に役立つと言えます。

于 2013-02-01T12:01:51.387 に答える
2

SSRS はスマートで、必要になるまで例外を保存することを覚えておくことが重要です。エクスポートする場合は、すべてのデータが抽出されます。また、オンラインで表示していて、行の展開と折りたたみがある場合、それらは表示するまで実行されません。その理論では、基本的な SQL が推奨されます。

レポートはどのような場合でも Tablix で集計を試みるため、集計は SSRS に任せるのが最善です。グラフに関しては、Tablix も持っていない限り、集計することをお勧めします。

比較などの単純な計算は、SQL で行う必要があります。

SSRS はあなたより賢いことを思い出してください ;) そして、最も単純な SQL がこのサービスを最適に機能させ、このサービスは主に表示用です。

データセットに MS SQL サーバーを使用すると、サービスが最適に機能します。

于 2013-02-02T00:12:41.477 に答える