SSRSで行グループ式を使用するとプレビューが非常に遅くなる

Question

5つの行グループを持つ階段状のレポートがあります。それぞれは、グループ化する値として式を使用します。ユーザは最大5つの異なるパラメータの値を選択し、それらのパラメータに基づいて、レポートのグループ化方法を選択できます。

特定のパラメータの組み合わせでは、レポートはVisual Studioのプレビューウィンドウで2分以上かかる場合があります。レポートをSSRSサーバーにデプロイすると、同じパラメーターの組み合わせが10秒以内に実行されます。好奇心から、私はレポートのコピーを作成し、それぞれの行グループから式を削除し、グループ化するフィールドを指定しました。その場合、サーバーで表示されたときと同じくらい早くプレビューされます。

誰でも何が起こっている可能性がありますか？あなたはそれがサーバーと同じコンピューティングパワーを持っていません開発マシンでレポートを実行している場合

は、私は現在、明らかにVisual Studioのエンタープライズアップデート3.

Answer 1

まず、ビットを使用しています。サーバーからVSを実行している場合でも、展開されたレポートほど速く実行されません。

パフォーマンスが低下する原因はグルーピング式です。あなたのレポートが処理に時間がかかるようですので、この記事はTechnetの投稿からチェックしてください。

Tablixデータ領域のネストされたグループと隣接するグループの多くのレベルでは、レポート処理のパフォーマンスに影響を与えることができます。 グルーピングのレベル、グループインスタンスの数、グループの式が適用された後の評価が必要な集約 関数の使用の両方を考慮してください。

SQLレベルのデータソースでグループ化を実行することをお勧めします。クエリにパラメータを渡して、そこで目的のグループを設定することもできます。

これが役立つかどうか教えてください。

Answer 2

これは古い問題だとわかりましたが、これはあなたに役立つかもしれません。

これまで説明した内容と同様の現象が発生していますが、グループ化ステートメントで動的フィールドを使用することになります。どうやら、他のステートメントでは問題なくダイナミックフィールドを使用できますが、グループ化するとパフォーマンスが大幅に低下します。

このlinkは、症状と原因を概説しています。

特定のリンクに含まれているかどうかわかりませんが、HTMLにレンダリングするときのReportViewerコントロールのバグは、コントロールが.Net 4.0または高い。 .Net 3.5では、レポートビューアアプリケーションでRDLを実行する場合とほとんど変わりません。

レポートビューアコンポーネントを動作させる最も簡単な方法は、IIS 2.0が実行されているアプリケーションプール（またはそのオプションがある場合は3.5）基本的に同じことです）。

アプリケーションで.Net 4を使用している場合。0以上であれば、グループから動的参照を削除するためにレポートを書き直すのに手間がかかりませんでしたが、レポートの対話性が大幅に低下します（表の展開/折りたたみオプションなし行/列）。

参考までに、クエリに約2分かかりましたが、SSRSでRDLをロードした後にほぼ即座にレンダリングされるというレポートがありました。 .Net 2.0でReportViewerコントロールを使用してレンダリングした同じレポートは、完全レンダリングに約2分30秒かかりました。まったく同じコードを使用していますが、.Net 4.0を使用するようにアプリケーションプールを変更すると、レポートは現在約15分間「レンダリング」されていますが、まだ戻っていません。