3个 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有关的性能问题。

我期待您的反馈和在下面评论。

真诚地,

David Magar

Windows Azure SQL Reporting程序经理

本文翻译自:http://blogs.msdn.com/b/windowsazure/archive/2012/12/07/aa.aspx

 

Comments (0)

Skip to main content