Windows Azure SQL Reporting開發的最佳做法

編者注：這篇博客文章來自Windows Azure SQL Reporting 專案經理David Magar。

儘管人們傾向于採用一個現有的Reporting Services專案，並且把它放置到雲上，你確實不應該這樣做。 在本機伺服器運行良好的報表部署到SQL Reporting報表服務器也許沒有本機伺服器上同樣的性能。

很幸運，3個簡單的修改就可以產生更快的運行報告。 這篇博客文章將詳細講述每一個修改。

最佳做法#1： 重新配置 ReportViewer 控制項

如果你在ASP.Net頁或者Windows forms應用程式中使用ReportViewer 控制項(RVC)，你需要更改以下的配置：

1.通過調用：WebRequest.DefaultWebProxy = null， 在您的應用程式初始化中禁用預設的代理伺服器；

2.通過配置應用程式的RVC使用cookie進行身份驗證，而不用進行日誌調用。 這將強制你的使用者或者應用程式登陸一次，稍後返回一個cookie為了更快的呈現。 請記住，Report Server僅僅允許在60分鐘內創建的cookie，因此當設計你的應用程式的時候，你必須把這個cookie應用到帳戶。

3.   調用SetParameters 和not SetParameter，同時設置所有 Windows Azure SQL 報告參數。 設置參數導致調用在Windows Azure SQL Database中的Windows Azure SQL Reporting資料層。 通過發出一個調用而不是幾個，對減少讀\寫週期有很多説明。

最佳做法 #2： Co-locate Web 應用程式和在相同資料中心的資料庫。

ReportViewer控制項和報表伺服器頻繁通信。 這種行為不可避免，但是通過在同一個資料中心中部署你的Windows Azure應用程式和報表伺服器，你可以最小化成本。

當選擇在哪裡部署你的Windows Azure SQL資料庫時，這種注意事項同樣適用。 發送到SQL Database的每一個查詢都帶有一定量的系統花費。 在頁面呈現時身份驗證、 授權、 處理請求，等等所有的這些操作有助於在初始連接之間延遲。 將資料庫放在同一個資料中心，採取這種行為其他應用程式減少了時間，節約了呈現時間並且產生更好的性能。

通過閱讀來自我們團隊David Bahat的博客文章，您可以檢測到您的資料庫、 應用程式和報表伺服器的位置，以及瞭解為每個報表轉譯引入資料確切它花費多少時間。

最佳做法 #3： 編寫高效的查詢

當創作報告時，設置可以僅僅帶來報告視覺化需要的資料（當設計查詢時，尤其避免「Select *」 SQL聲明類型）。 這種最佳的做法確保你的報告最快的呈現。

最後，我希望這3個建議有助於解決一些與應用程式和SQL Reporting有關的性能問題。