Known Issue: Reporting Services への初回アクセス時に、レポート表示に時間がかかる。

小林 真治
SQL Developer Support Escalation Engineer

今回は、同一レポート/データを利用した際のレポートの表示パフォーマンスが悪化する現象における、 Reporting Services の既定の動作に起因したパフォーマンス悪化の要因として考えられること、並びに対処策について解説します。

同一レポート/データを利用した際にレポートの表示パフォーマンスが通常より遅い場合、一般的には、該当レポートを表示した際の同時実行性に起因したサーバーリソースの枯渇が要因として考えられます。
しかしながら、ある特定の時間において １回だけ表示パフォーマンスが遅い場合や、 Reporting Services サービスを再起動した直後に表示パフォーマンスが遅いなどの現象が発生している場合、下記の動作に起因している可能性があります。

Reporting Services は、下記イベントが発生した場合、イベント発生後に最初にリクエストされたレポートを表示するタイミングで、自身が動作するために必要なモジュールを読み込みます。
このため、これらのイベントの直後、レポートを表示するまでに時間がかかることがあります。

- Reporting Services のサービス再起動後

- Reporting Services の定期的なリサイクル処理発生後 (既定で 12 時間毎)

- 他、レポートサーバー、および、ASP.NET の構成変更やメモリ不足とメモリ割り当て失敗時などのタイミング

尚、一番初めにリクエストされたレポートを表示するタイミングで Reporting Services は、下記を実施しています。 

- Reporting Services プロセス内 Web サービス用アプリケーションドメインの生成

- Reporting Services プロセス稼働に必要なモジュールの読み込み

このため、それぞれのイベント発生後の最初のレポート表示は、通常より遅延する可能性があり、残念ながら、この動作を Reporting Services のパラメータや構成などで制御することはできません。
しかしながら、 上記動作をユーザーによるレポート表示要求よりも先に実施させることで、最初のレポート表示時におけるパフォーマンス悪化を緩和することが可能です。

一例とはなりますが、バッチでのレポートサーバーへのアクセスする方法について記載しました。
下記スクリプトを、「ReportServerAccess.vbs」等の名称で保存し、「cscript ReportServerAccess.vbs」と実行することで、ユーザーが最初のレポート表示遅延に遭遇する可能性を抑制できます。

----ここから------

Option Explicit

' 該当のレポートサーバーのURL を指定

Const cURL = "https://localhost/ReportServer/"

 Dim oIE, stUrl

 WScript.Echo("Set Variables")

stUrl = cURL

 ' IE を起動

WScript.Echo("Create IE Object.")

Set oIE = CreateObject("InternetExplorer.Application")

 WScript.Echo("Make IE visible.")

oIE.Visible = true

 WScript.Echo("Change IE size.")

oIE.width = 800

oIE.height = 600

 ' 該当ページに移動

WScript.Echo("Go to URL = " & stUrl)

oIE.Navigate stUrl

 ' IE のロードを待つ

WScript.Echo("Waiting for IE.")

Call WaitIE

 ' 終了前に少し待つ

WScript.Sleep(10000)

 ' 終了

oIE.Quit()

Set oIE = nothing

 ' ============================================================================

' WaitIE  (IE のロードを待つ)

' ============================================================================

Sub WaitIE

Do While oIE.busy

WScript.Echo("Waiting for loading page...")

WScript.Sleep(1000)

Loop

 Do While oIE.Document.readyState <> "complete"

WScript.Echo("Waiting for rendering page...")

WScript.Sleep(1000)

Loop

End Sub

 ----ここまで------

 ※ 留意事項
本サンプルは、本ブログの説明の為のものとなり、弊社にてその動作を保証するものではございません。
ご使用の際には、ご利用のシステムに合わせて修正して頂き、十分なテストを実施して頂きます様お願い致します。 
サンプル内で使用しております API などの詳細な情報に関しては、MSDN 、PlatformSDK などをご参照ください。

Comments

• Anonymous
  June 28, 2012
  以下の記述ですが、もう少し詳細に教えていただきたいです。 マニュアルに詳しく書かれている個所はありますか？ > 同一レポート/データを利用した際にレポートの表示パフォーマンスが通常より遅い場合、 > 一般的には、該当レポートを表示した際の同時実行性に起因したサーバーリソースの枯渇が > 要因として考えられます。

• Anonymous
  December 16, 2012
  ogata さん、こんにちは。 小林です。 ご質問ありがとうございます。 大変残念ながら、ご指摘いただきました箇所についてマニュアルなどに詳細な記述はございませんので、この場を借りてご指摘の箇所について補足させてください。 Reporting Services 上のレポートを参照した際に、初回アクセス時だけでなく、再表示してもパフォーマンスが遅い場合、ご指摘の記述部分の要因に起因している可能性があります（例えば、初回実行時を除く、2回目、3回目のレポート再表示が 4 回目の再表示より明らかに遅い場合などを想定ください）。 再表示してもレポートのパフォーマンスが遅い場合、Reporting Services としては（ユーザーとしても）、同じレポートに対して同じ検索条件でレポート表示を実行していることになります（つまり同一レポート/データを利用していることになります）。 この場合、2-4回目におけるレポートの再表示処理は Reporting Services としては同じ処理が実行されますので、2,3回目は遅く、4回目が早い、となった場合、レポートの再表示処理そのものではなく、何らかの別の要因に起因してパフォーマンスの差違がでていることが想定されます。 このような状況において「何らかの別の要因」として最も疑われるものが「同時実行性に起因したサーバーリソースの枯渇」となります。 Reporting Services を複数ユーザーにて参照している場合、同時に実行されるレポート処理数は増大します。このような状況下では複数のレポート処理が実施されますので、この処理を実施するために Reporting Services が動作するサーバーのサーバーリソースが枯渇する可能性があります。実際にサーバーリソースが枯渇した場合、レポート処理をするためのボトルネックとなりますので、レポート処理が待たされ、パフォーマンスが遅くなります。 サーバーリソースの枯渇については、このような現象発生時にパフォーマンスモニタなどで、サーバーのパフォーマンスを監視することで確認できます。