6

UPDATE 2.4.2010 ええ、これは古い質問ですが、最新情報を提供すると思いました。そのため、ReportViewer を再度使用していますが、最初の読み込みでレンダリングが遅くなります。唯一の違いは、SQL データベースがレポート サーバー上にあることです。

更新 3.16.2009

プロファイリングを行いましたが、最初の呼び出しで ReportViewer のレンダリングを遅らせているのは SQL ではありません。最初の呼び出しで、ReportViewer コントロールが UI スレッドをロックし、プログラムが応答しなくなります。約 5 秒後、ReportViewer は UI スレッドのロックを解除し、「レポートが生成されています」と表示し、最後にレポートを表示します。5 秒が大したことではないことはわかっていますが、これは起こるべきではありません。私の同僚は彼のプログラムで同じことを行い、ReportViewer は要求があればすぐに「レポートが生成されています」と表示します。

唯一の違いは、レポート サーバーが 1 つのサーバーにあり、データが別のサーバーにあることです。ただし、SSRS 内でレポートを作成している場合、遅延はありません。

アップデート

ReportViewer の最初の読み込みだけに時間がかかることに気付きました。同じまたは異なるレポートの後続の各ロードは高速にロードされます。

ReportViewer.RefreshReport() メソッドが呼び出されると、レンダリングに最大 30 秒かかる可能性のあるリモート処理モードで使用しているWinForms ReportViewer があります。ただし、レポート自体は高速に実行されます。

これは、ReportViewer をセットアップするためのコードです。

rvReport.ProcessingMode = ProcessingMode.Remote
rvReport.ShowParameterPrompts = False
rvReport.ServerReport.ReportServerUrl = New Uri(_reportServerURL)
rvReport.ServerReport.ReportPath = _reportPath

これは、ReportViewer がレンダリングするのに最大 30 秒かかる場合がある場所です。

rvReport.RefreshReport()
4

11 に答える 11

4

私は他のフォーラムで答えを見つけました。 MSDNは、DLLがVerisign Webサーバーを検索していて、それが永遠にかかると説明しています...それをオフにする方法は2つあります。1つはInternet Explorerのチェックボックスで、もう1つはアプリのapp.configファイルにいくつかの行を追加します。 。

于 2010-04-29T19:11:21.007 に答える
3

レポートは、ローカルとサーバーの2つのモードでプルできます。ローカルモードで実行している場合は、データとレポート定義の両方をマシンにプルしてから、両方をレンダリングします。サーバーモードでは、SSRSにすべての作業を任せてから、情報をプルバックしてレンダリングします。

ローカルモードを使用している場合は、ハードウェアの問題である可能性があります。巨大なデータセットがある場合、それはメモリに保存 する大量のデータです。

それ以外は、それは続けるべき多くの情報ではありません...

更新：時間がかかるのは最初の呼び出しだけであることに気付いたので、作業の大部分がバックエンドSQL呼び出しで行われるのか、実際のレポートレンダリングに費やされるのかを判断するためのプロファイリングを行いましたか？

後続の呼び出しで高速である場合は、（偶然に）あるレベルまたは別のレベルでキャッシュしている可能性があります。レポートをキャッシュするか（http://www.sqlservercurry.com/2007/12/configure-report-to-be-cached-ssrs-2005.html）、データを返す実行プランがキャッシュされている可能性がありますSQLServerの奥深く。

于 2009-01-10T03:57:51.887 に答える
3

すでに提示されたさまざまなアイデアを要約すると、次のようになります。

  • クライアント上のレポート ビューアー インフラストラクチャの起動時間
  • クライアントでのキャッシュ読み込み時間
  • サーバーでのクエリ実行時間
  • サーバーでのレンダリング時間の報告

レポートの実行、クライアントの終了、クライアントの再起動、レポートの再実行を試してください。2 回目のレポートがはるかに高速である場合は、この実験を繰り返しますが、レポートの実行の間に別の大きなアプリケーションをロード、実行、およびアンロードします。

2 番目のレポートの実行が引き続きはるかに高速である場合、表示されている違いは、クライアントで起こっていることよりも、SQL Server の I/O キャッシュに関係しています。レポートで使用されていないテーブルから大量のデータを取得するクエリを実行して、MSSQL キャッシュを意図的に置き換えることで、これをさらにテストできます。

上記はすべて興味深いものですが、重要ではありません。迅速なレポート応答を確保したい場合、Reporting Services はスケジュールされたレポートの生成を広範囲にサポートしているため、消費者がレポートを要求したときの唯一の遅延はネットワーク配信です。

ユーザーが最新の (ライブ) データのレポートを要求する場合は、より厳しい制約パラメーターを指定するか、待機に慣れる必要があります。

于 2009-03-17T00:46:25.100 に答える
3

ReportServer は IIS で実行されているため、起動するのに常に時間がかかります。各 AppPool にはプロセス タイムアウトがあります。ASP.NET アプリケーションのレポート ビューアにも同じ問題があります。IIS 設定で AppPool キープアライブ時間を増やしてみてください。

ここを参照してください：

もちろん、SQL2005 SSRS を実行していると仮定しています。

1 つのオプションは、SSRS が IIS に依存しなくなった 2008 にアップグレードすることです。

于 2009-03-16T12:10:51.750 に答える
2

私はこれと同じ問題を抱えていました。

デフォルトのプリンタ（ここでは低速ネットワーク）を変更すると問題が解決することがわかりました。

ReportViewerはデフォルトのプリンターからいくつかの情報を取得しますが、ここのネットワークは非常に遅いため、10秒の遅延がありました

それが役に立てば幸い

于 2010-04-16T20:46:14.103 に答える
2

箱から出して考える方法：レポートサーバーは、アプリケーションを実行しているマシンとは別のマシンにありますか？ネットワークが「reportServerURL」を解決するのに長い時間がかかる可能性があります。解決されると、名前がキャッシュされるため、後続の呼び出しが高速になります。

以前、DNSサーバーの構成が不適切な場合にこの問題が発生しました。「reportServerUrl」を「reportServerIPAddress」に置き換えてみて、ReportViewerへの最初の呼び出しがもっと速いかどうかを確認してください。

于 2009-01-17T18:49:08.787 に答える
1

アップデート

ReportViewer の最初の読み込みだけに時間がかかることに気付きました。同じまたは異なるレポートの後続の各ロードは高速にロードされます。

于 2009-01-14T15:34:17.500 に答える
1

SSRSレポートを直接追いかけているようです。代わりに、SSRS Web サービスにアクセスすることをお勧めします。これにより、パフォーマンスが向上する可能性があります。

于 2009-03-17T12:07:10.520 に答える