报告服务中的视图状态
我在一家公司担任顾问，该公司的 Reporting Services 2005 服务器中有大约 30 份报告。所有报告都使用大约 10 个参数来更改加载到报告中的数据。这些参数也相互依赖。
问题在于，报告会导致展位更改参数和处理/加载最终报告的加载时间较长。除此之外，报告会生成大约 110 000 个字符长的大视图状态，这可能会影响报告回发到服务器时的较长加载时间。
我检查了 t-sql 和存储过程处理时间，当我使用 sql profiler 时它们看起来很正常。因此，它必须与渲染过程和具有大量视图状态的报告回发有关...
您可以像在 asp.net webforms 中那样在不同控制器的报告服务报告中禁用视图状态吗？或者最终用户是否必须忍受较长的加载时间。
I work as a consultant at a company that have around 30 reports in a reporting services 2005 server. All of the reports use around 10 parameters to change the data loaded into the report. The parameters is depending on eachother also.
The problem is that the reports causes long loadtimes for booth changing parameter and processing/loading the final report. On top of this the report generate a big viewstate around 110 000 char long, and this probably impact the long loading time when report is being postbacked to server.
I have checked t-sql and stored procedures processing time and they look normal when i use sql profiler. So it must have to do with the rendering process and postback of report with the heavaly viewstate...
Can you disable viewstate in reporting services reports for different controllers like you can in asp.net webforms ? Or do end user have to live with the long loading times.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们的网络负载均衡器遇到了问题。
我们有一些包含 10-20 个参数的大型报告，但我们在开发/UAT 方面还不错，但生产速度慢得多，而且参数回发很糟糕。
在公司网络上，110k 是微不足道的，所以它可能是基础设施/配置，而不是与 RS Web 应用程序相关的
备忘录：我真的应该解决这个问题......
We have issues via our web load balancer.
We have some big reports with 10-20 parameters but we're OK on Dev/UAT but prod is a lot slower and parameter post backs are bad.
On a corporate network, 110k is peanuts so it may be infrastructure/config rather then RS web app related
Memo to me: I really should fix this...