Windows Azure SQL レポートを使用した開発に関する 3 つのベスト プラクティス

このポストは、12 月 7 日に投稿された 3 best practices for Windows Azure SQL Reporting development の翻訳です。

編集メモ : 今回は、Windows Azure SQL レポート担当プログラム マネージャーを務める David Magar の投稿をご紹介します。

「Reporting Services の既存プロジェクトをそのままクラウドに移して使用したい」とお考えになる方も多いかと思いますが、あまりおすすめできる方法ではありません。ローカル サーバーで快適に動作するレポートを SQL レポートのレポート サーバーに展開しても、同様のパフォーマンスを得られるとは限らないためです。

しかし幸いなことに、3 つの簡単な修正を加えるだけで、ほとんどの場合にレポートのパフォーマンスを向上させることができます。今回は、その修正方法について、それぞれ詳しく解説します。

ベストプラクティス #1: ReportViewer コントロールを再構成する

ASP.NET ページや Windows フォーム アプリケーションで ReportViewer コントロール (RVC) を使用している場合、以下のとおり構成を変更します。

1.WebRequest.DefaultWebProxy = null を呼び出して、アプリケーション初期化時の既定プロキシを無効にします。

2.SetParameters を呼び出して、Windows Azure SQL レポートのすべてのレポート パラメーターを一度に設定します (SetParameter とは異なりますので、注意してください)。パラメーターを設定すると、Windows Azure SQL データベースに配置された Windows Azure SQL レポートのデータ層への呼び出しが行われます。これらの呼び出しを 1 回にまとめることで、読み取り/書き込みサイクルが減少し、パフォーマンスが大幅に向上します。

3.ログオン呼び出しを実行する代わりに Cookie を使用して認証を行うよう、アプリケーションの RVC を構成します。これにより、ユーザーやアプリケーションが一度ログインを行うと Cookie が返されるため、レンダリングが高速化されます。ただし、レポート サーバーは生成後 60 分以内の Cookie しか許可しません。アプリケーション設計時には、この点を考慮する必要があります。

ベストプラクティス #2: Web アプリケーションとデータベースを同じデータセンターに併置する

ReportViewer コントロールは、レポート サーバーと高い頻度で通信します。この動作自体をなくすことはできませんが、Windows Azure アプリケーションとレポート サーバーを同じデータ センターに展開することで、そのコストを最小化することが可能です。

Windows Azure SQL データベースの展開場所についても、同様のことが言えます。SQL データベースにクエリが送信されるたびに、一定のオーバーヘッドが発生します。認証、承認、要求の処理などのすべてのアクションが、最初の接続からページのレンダリングまでにかかる時間を長引かせる要因となっています。データベースを他のアプリケーション コンポーネントと同じデータ センターに配置することで、これらのアクションに要する時間を短縮できます。その結果、レンダリング時間が大幅に節減され、パフォーマンスが向上します。

データベース、アプリケーション、レポート サーバーの配置場所の検出方法と、各レポートのレンダリング用データの収集にかかる時間を正確な測定方法については、Windows Azure SQL レポート チームの David Bahat がこちらのブログ記事 (英語) で紹介しています。

ベストプラクティス #3: 効果的なクエリを記述する

レポートを作成する際、レポート表示に必要なデータのみを収集するようにクエリを設定します (具体的には、"Select *" 型の SQL ステートメントを使用せずにクエリを作成します)。この方法により、レポートを高速レンダリングに最適化させることができます。

今回提案した 3 つの方法が、SQL レポートを使用するアプリケーションのパフォーマンス問題を解決するうえで、お役に立てば幸いです。ぜひ、ご意見やご感想を以下のコメント欄にお寄せください。

最後までお読みいただき、ありがとうございました。 David Magar (Windows Azure SQL レポート担当プログラム マネージャー)