レポート サービスが 1 MB のデータを返したときに、レポートの生成にかかる時間を分単位で知りたいだけです。ビューとテーブルを使用すると、適切にインデックスが作成される可能性があります。SSRS レポートとサーバー側の生成。
5 に答える
レポートの生成時間には、次の2つの要素があります。-データ取得時間-レンダリング時間
では、1 Mbのデータの場合、何レコード(行)を話しているのでしょうか。レポートには何ページありますか?1ページにいくつのコントロールがありますか?レポートはグラフを使用していますか?これらは、生成時間を決定する要因です。
ほとんどのレポートでは、データ取得時間が最も重要な要素です。レポートは、生データの取得よりも速く実行されることはありません。したがって、SQLを使用している場合、クエリの実行に必要な時間よりも速くレポートを生成することはできません。1Mbをはるかに超えるデータを非常に迅速に返すクエリを見てきました。また、データをほとんど返さず、長時間実行されるクエリも確認しました。
レンダリング側では、レポートの実行が遅くなる原因となることがいくつかあります。1つ目は、レポートの集計です。レポートがレンダリングを開始する前にすべてのレコードを受信する必要がある場合、そのパフォーマンスは低下します。特に、レポートツールによっては。大規模なデータセット(10,000レコードを超える)では、ソース(DB)で集計を行うことにより、レンダリングを大幅に改善できます。もう1つはチャート作成です。これには通常、レンダリングのオーバーヘッドと集計が多く含まれます。
ほとんどのレポートシステムでは、レポートのパフォーマンスを調整するのに役立つタイマーまたはロギングを組み込むことができます。レポートにデータの取得に費やされている時間の割合と、レンダリングに費やされている割合を示すタイマーをレポートに組み込むのが最適です。あなたがこの情報を持っているとき、あなたはあなたのエネルギーをどこに集中させるべきかを知るでしょう。
レポートツールのパフォーマンスを実際に評価しようとしている場合、最良の方法は、フラットファイルを読み取るか、コードを介してデータを生成するレポートを作成することです。つまり、データベースの影響を排除し、レポートツールがページを生成する速度を確認します。
お役に立てれば。
どのくらい許容できますか?それが何をしているのか、どれだけ実行されているのかなどによって異なります。30秒未満であれば、1日1〜2回実行すれば問題ありません。週に1回、または月に1回実行する場合、その数ははるかに多くなる可能性があります。
レポート自体は一般的に非常に高速です。ハングアップが発生した場合は、データを生成するクエリの実行時間を確認することをお勧めします。複雑なクエリは、ほんの少しのデータしか返さない場合でも、長い時間がかかる可能性があります...
何人かがすでに言ったように、このような一般的な質問には答えられません。ただし、レポート速度をターボチャージする – 一般的なルールとガイドライン(免責事項 - 私は、SSRS の競合企業である Windward Reports の CTO です) を作成しました。プロセスをスピードアップするために何ができるかを探すのに役立つと思います。
また、詳細に関するすべての注意事項は非常に重要であり、3 GHz ワークステーションでは通常、1 秒あたり 7 ~ 30 ページが表示されます。これは SSRS ではなく Windward の数値であることに注意してください。
BIRT やその他のレポート システムを使用している場合、バックエンドでほとんどの作業をデータベースにオフロードすることで、最良の改善が得られる傾向があることがわかりました。
つまり、ネットワーク経由で大量のデータを送信したり、ローカルで並べ替えたりグループ化したりしないでください。データベースは、SQL の orderby 句と groupby 句、およびインデックスの最適化 (とりわけ) により、ほぼ確実に優れたパフォーマンスを発揮します。
こうすることで、必要なデータをより迅速に抽出し、ネットワーク トラフィックを減らすことができます。