0

レポート サービスが 1 MB のデータを返したときに、レポートの生成にかかる時間を分単位で知りたいだけです。ビューとテーブルを使用すると、適切にインデックスが作成される可能性があります。SSRS レポートとサーバー側の生成。

4

5 に答える 5

4

レポートの生成時間には、次の2つの要素があります。-データ取得時間-レンダリング時間

では、1 Mbのデータの場合、何レコード(行)を話しているのでしょうか。レポートには何ページありますか?1ページにいくつのコントロールがありますか?レポートはグラフを使用していますか?これらは、生成時間を決定する要因です。

ほとんどのレポートでは、データ取得時間が最も重要な要素です。レポートは、生データの取得よりも速く実行されることはありません。したがって、SQLを使用している場合、クエリの実行に必要な時間よりも速くレポートを生成することはできません。1Mbをはるかに超えるデータを非常に迅速に返すクエリを見てきました。また、データをほとんど返さず、長時間実行されるクエリも確認しました。

レンダリング側では、レポートの実行が遅くなる原因となることがいくつかあります。1つ目は、レポートの集計です。レポートがレンダリングを開始する前にすべてのレコードを受信する必要がある場合、そのパフォーマンスは低下します。特に、レポートツールによっては。大規模なデータセット(10,000レコードを超える)では、ソース(DB)で集計を行うことにより、レンダリングを大幅に改善できます。もう1つはチャート作成です。これには通常、レンダリングのオーバーヘッドと集計が多く含まれます。

ほとんどのレポートシステムでは、レポートのパフォーマンスを調整するのに役立つタイマーまたはロギングを組み込むことができます。レポートにデータの取得に費やされている時間の割合と、レンダリングに費やされている割合を示すタイマーをレポートに組み込むのが最適です。あなたがこの情報を持っているとき、あなたはあなたのエネルギーをどこに集中させるべきかを知るでしょう。

レポートツールのパフォーマンスを実際に評価しようとしている場合、最良の方法は、フラットファイルを読み取るか、コードを介してデータを生成するレポートを作成することです。つまり、データベースの影響を排除し、レポートツールがページを生成する速度を確認します。

お役に立てれば。

于 2008-09-25T16:12:57.553 に答える
1

どのくらい許容できますか?それが何をしているのか、どれだけ実行されているのかなどによって異なります。30秒未満であれば、1日1〜2回実行すれば問題ありません。週に1回、または月に1回実行する場合、その数ははるかに多くなる可能性があります。

于 2008-09-25T04:35:27.717 に答える
1

レポート自体は一般的に非常に高速です。ハングアップが発生した場合は、データを生成するクエリの実行時間を確認することをお勧めします。複雑なクエリは、ほんの少しのデータしか返さない場合でも、長い時間がかかる可能性があります...

于 2008-09-25T04:41:49.713 に答える
0

何人かがすでに言ったように、このような一般的な質問には答えられません。ただし、レポート速度をターボチャージする – 一般的なルールとガイドライン(免責事項 - 私は、SSRS の競合企業である Windward Reports の CTO です) を作成しました。プロセスをスピードアップするために何ができるかを探すのに役立つと思います。

また、詳細に関するすべての注意事項は非常に重要であり、3 GHz ワークステーションでは通常、1 秒あたり 7 ~ 30 ページが表示されます。これは SSRS ではなく Windward の数値であることに注意してください。

于 2011-05-28T20:24:43.830 に答える
0

BIRT やその他のレポート システムを使用している場合、バックエンドでほとんどの作業をデータベースにオフロードすることで、最良の改善が得られる傾向があることがわかりました。

つまり、ネットワーク経由で大量のデータを送信したり、ローカルで並べ替えたりグループ化したりしないでください。データベースは、SQL の orderby 句と groupby 句、およびインデックスの最適化 (とりわけ) により、ほぼ確実に優れたパフォーマンスを発揮します。

こうすることで、必要なデータをより迅速に抽出し、ネットワーク トラフィックを減らすことができます。

于 2008-09-25T05:16:49.393 に答える