Sql Reporting Services 2005での巨大なレポートのPDFエクスポートの最適化

Question

まず、非常に大規模な/長時間実行されているレポートを実行するのは恐ろしい考えです。 Microsoftは、SSRSレポートの実行に30秒以上かかることはないという経験則を持っていることを認識しています。しかし、時には巨大な報告が、州法を遵守するような外部の力のために好ましい悪である場合もある。

私の雇用場所には、Crystal ReportsからSSRSに移行したasp.net（2.0）アプリケーションがあります。大規模なユーザーベースと複雑なレポートUI要件のため、ユーザー入力のパラメータを受け入れ、夜間に実行するスケジュールを作成する一連の画面が用意されています。アプリケーションが複数のレポーティングフレームワークをサポートしているので、SSRSのスケジューリング/スナップショット機能は使用しません。システム内のすべてのレポートは、ユーザが入力したパラメータを取得し、レポートが作成された対応するレポートソリューションでレポートを生成する、スケジュールされたコンソールアプリケーションによって生成されます。 SSRSレポートの場合、コンソールアプリケーションはSSRSレポートを生成し、SSRS WebサービスAPIを介してPDFとしてエクスポートします。

これまでのところ、SSRSはCrystalよりも扱いがずっと簡単でしたが、最近Crystal ReportsからSSRSに変換された25,000ページのレポートがありました。 SSRSサーバーは64bit 2003サーバーで、SSRS 2005を実行する32ギガビットのRAMを搭載しています。小さなレポートはすべて機能しますが、このような大きなレポートには問題があります。残念ながら、WebサービスAPIを介して上記の報告書を生成することはできません。次のエラーは、生成/エクスポートに約30-35分発生します。

例外メッセージ：基になる接続がクローズされました。受信時に予期しないエラーが発生しました。奇妙なことは、レポートがレポートサーバー上で直接実行されている場合、このレポートは/レンダリング/エクスポートを実行することである

data = rs.Render(this.ReportPath, this.ExportFormat, null, deviceInfo, 
    selectedParameters, null, null, out encoding, out mimeType, out usedParameters, 
    out warnings, out streamIds); 

：前

Webサービスの呼び出しは、私はあなたのすべてを見ていると確信しているものですレポートマネージャを使用します。レポートのデータを生成するprocは約5分間実行されます。このレポートは、約12分後にブラウザ/ビューアでSSRSネイティブ形式でレンダリングされます。レポートマネージャのブラウザ/ビューアを使用してpdfにエクスポートするには、さらに55分かかります。これは確実に動作し、無作為に1.03gbのpdfを生成します。

• レポートに3時間 サーバー
• へのhttpRuntime ExecutionTimeout 値を設定します。ここでは

  は、私はレポートは、WebサービスAPIを介して作業を取得しようとした、より明白なものの一部であります無効なHTTPは

• が
• がサーバー上でタイムアウトしたことがないようにレポートを設定し、レポートサーバー上でスクリプトのタイムアウトを増加し、レポートサーバー上のキープアライブを
• クライアントコールでレポートのタイムアウトを数時間に設定する

私が試した調整から、タイムアウトの問題がなくなったと言っても大丈夫です。

エラーメッセージの調査に基づいて、WebサービスAPIはデフォルトでチャンクレスポンスを送信しないと考えています。つまり、1つの応答ですべての1.3Gbをワイヤで送信しようとします。ある時点で、IISはタオルを投げます。残念ながら、APIはWebサービス設定を抽象化していないので、応答チャンクを有効にする方法を見つけることができないようです。

1. PDFエクスポートフェーズやPDFのサイズを減らしたり、最適化したりするには、とにかく誰も知っていますか？
2. SSRSの応答チャンクを有効にする方法はありますか？
3. これは他の理論がありますが、これはなぜサーバー上で実行されますが、APIでは実行されないのですか？

編集：kcrumleyの投稿を読んだ後、ファイルサイズ/ページ数を取って平均ページサイズを調べ始めました。興味深いことに、小さなレポートでは、各ページが約5Kになるように数学が機能します。興味深いことに、レポートが大きくなると、この「平均」が増加します。たとえば、8000ページのレポートは平均40K /ページです。非常に奇妙な。また、各グループの最後のページを除いて1ページあたりのレコード数が設定されているので、一部のページでは他のレコードより多くのレコードがあることはありません。

Answer 1

1. 誰もが は、総ページ数を低下させることなくPDF書き出し相 及びまたはPDFのサイズを最適化/削減とにかく のを知っていますか？
   1.これは、グラフィックスを多用レポートです：

私はいくつかのアイデアとの質問がありますか？そうでない場合は、テキストとして始まり、SSRS PDFレンダラでグラフィックに変換されたテーブルがありますか（PDFでテキストを選択できるかどうかを確認してください）。情報の密集度に応じて1ページあたり41Kを超える必要があります。そうでない場合もあります。しかし、SSRS PDFレンダラーが「手を叩く」結果となってテーブルをテキストではなく画像としてレンダリングするような、ページの余白に表をぼかすなど、レポートのレイアウトに軽微な問題があったケースがありました。明らかに、レポート内のグラフィックスが少ないほど、ファイルサイズは小さくなります。
2.簡単にレポートを分割する方法はありますか？たとえば、10の場所のレポートで、最終的なレポートで場所1の後に場所2などがある場合、場所2の部分などとは独立して場所1の部分を実行できますか？もしそうなら、あなたはそれらをすべて受け取った後にPDFSharpを使って10のサブレポートを1つの最終的なPDFにすることができます。これはページの番号付けでいくつかの困難につながりますが、克服できないものはありません。

3.誰がこの サーバー上で動作する理由としてではなく、APIを介して、他の の理論を持っていますか？

私の推測では、レポートの膨大なサイズになります。私はIIS設定とSSRS固有のものについて何も覚えていませんが、大量のデータを渡すことさえ可能にするために更新する必要があるIIS全体の設定（おそらくMetabase.xml）があるかもしれません。

WAITFORを使用するストアドプロシージャ（DBMS用にSQL Serverを想定）で作業レポートを作成し、長い待ち時間でビルドすることで、時間に問題があるかどうかの問題を特定できます。

それ自体が解決策ではなく、アイデアです。それが役に立てば幸い。

Answer 2

明らかに、その巨大なレポートは、実際にはレポートよりも1.3GBのデータベースに近いものです。

複数の部分に分割して組み合わせる方法を考えましたか？ （本サイトに掲載されているPDFファイルを結合するには、いくつかの異なる方法のいずれかを使用します。）

Answer 3

我々はSSRSから大規模なPDFエクスポートを絞り込ん、見つかった2つの主要な犯人

1）の画像がJPGまたはPNGのカラータイプ3でない限り、彼らは5 'standard' PDF fontsの一つである場合を除き、彼らはあなたがそうでなければ（推奨しません動作するようにSSRSを設定しない限り、BMPの参照here

2））に拡張され、その後、SSRSは、PDFにフォントやフォントのサブセットを埋め込みます。

ほとんどのWindows OSに標準のフォント（Symbol以外のものはありません）はインストールされていませんが、Times New Roman, Courier New, or Arialを使用した場合、順方向および逆方向のフォントの置き換えが行われます。

RDLを変換する最も簡単な方法は、XMLとして表示し、FontFamilyというタグを検索して置き換えることです。いくつかのフォントとして

• 使用することができますように：あなたは非標準のフォントを使用する必要がある場合

  は、その後、あなたはまだ被害を最小限に抑えることができます。 RDL XMLを検索して、冗長なフォントがないことを確認します。

• 異なるフォントサイズを使用する場合は、TTFフォントを使用してください。
• フォントの通常の太字と斜体の組み合わせを混ぜないようにしてください。そうでない場合は、複数回埋め込まれます。