3个 Windows Azure SQL Reporting开发的最佳做法

jorndbshvc

　　编者注：这篇博客文章来自Windows Azure SQL Reporting 项目经理David Magar。
　　尽管人们倾向于采用一个现有的ReportingServices项目，并且把它放置到云上，你确实不应该这样做。在本地服务器运行良好的报表部署到SQL Reporting报告服务器也许没有本地服务器上同样的性能。
　　很幸运，3个简单的修改就可以产生更快的运行报告。这篇博客文章将详细讲述每一个修改。
　　最佳做法#1： 重新配置 ReportViewer 控件
　　如果你在ASP.Net页或者Windows forms应用程序中使用ReportViewer 控件(RVC)，你需要更改以下的配置：
　　1.通过调用：WebRequest.DefaultWebProxy =null， 在您的应用程序初始化中禁用默认的代理服务器；
　　2. 调用SetParameters 和not SetParameter，同时设置所有 Windows Azure SQL 报告参数。设置参数导致调用在Windows Azure SQL Database中的Windows Azure SQL Reporting数据层。通过发出一个调用而不是几个，对减少读\写周期有很多帮助。
　　3.通过配置应用程序的RVC使用cookie进行身份验证，而不用进行日志调用。这将强制你的用户或者应用程序登陆一次，稍后返回一个cookie为了更快的呈现。请记住，Report Server仅仅允许在60分钟内创建的cookie，因此当设计你的应用程序的时候，你必须把这个cookie应用到账户。
　　最佳做法 #2： Co-locate Web 应用程序和在相同数据中心的数据库。
　　ReportViewer控件和报表服务器频繁通信。这种行为不可避免，但是通过在同一个数据中心中部署你的Windows Azure应用程序和报表服务器，你可以最小化成本。
　　当选择在哪里部署你的Windows AzureSQL数据库时，这种注意事项同样适用。发送到SQL Database的每一个查询都带有一定量的系统花费。在页面呈现时身份验证、 授权、 处理请求，等等所有的这些操作有助于在初始连接之间延迟。将数据库放在同一个数据中心，采取这种行为其他应用程序减少了时间，节约了呈现时间并且产生更好的性能。
　　通过阅读来自我们团队David Bahat的博客文章，您可以检测到您的数据库、应用程序和报表服务器的位置，以及了解为每个报表呈现引入数据确切它花费多少时间。
　　最佳做法 #3： 编写高效的查询
　　
　　当创作报告时，设置可以仅仅带来报告可视化需要的数据（当设计查询时，尤其避免“Select *” SQL声明类型）。这种最佳的做法确保你的报告最快的呈现。
　　最后，我希望这3个建议有助于解决一些与应用程序和SQL Reporting有关的性能问题。
　　我期待您的反馈和在下面评论。
　　真诚地，
David Magar
Windows Azure SQL Reporting程序经理
　　本文翻译自：http://blogs.msdn.com/b/windowsazure/archive/2012/12/07/aa.aspx