Question

虽然我理解这个问题相当模糊，因为我没有给你所有详细信息，我希望能够对我的代码或报告本身进行一些改进。加快他们的速度。我已经要求更多的硬件，但是被拒绝了。

public Stream GenerateReport(string reportName, string format)
{
    if (reportName == null)
        throw new ArgumentNullException("reportName");

    reportExecutionService.LoadReport(reportName, null);

    string extension;
    string encoding;
    string mimeType;
    ReportExecution2005.Warning[] warnings;
    string[] streamIDs;

    byte[] results = reportExecutionService.Render(format, null, out extension, 
        out encoding, out mimeType, out warnings, out streamIDs);

    return new MemoryStream(results);
}

报告本身每个都需要6-10秒。我已经缩小了Reporting Services本身的瓶颈。我应该从哪里开始寻找消除潜在的速度瓶颈。注意：已删除一些代码以保护无辜者。

Answer 1

虽然与您发布的代码没有直接关系，但在Reporting Services中编写报表时，您应始终考虑以下几个常规增强功能：

预加载报告表，以便它们已汇总在报告中汇总的所有数据。例如，如果报表数据源汇总了数千行数据并且需要将多个表连接在一起，那么您应该创建一个预聚合表，将所有数据连接在一起，并且已经按照报表所需的粒度汇总了数据。 / p>
如果要将参数传递到数据源，则聚合的基础表应具有与搜索表的方式相对应的聚簇索引。例如，如果报表仅显示单个客户和给定交易日期范围的数据，则应在客户和交易日期订购聚集索引。
过滤数据应该出现在数据源查询中，而不是出现在报表本身中。这意味着，如果您对报表进行参数化以便过滤数据，则应将参数传递给数据库，以便返回较小的数据集。不要返回大量数据然后过滤数据。使用多值参数时很容易犯这个错误，因为使用多值参数的开箱即用说明是在数据返回到Reporting Services之后过滤数据。

我希望你已经在做上述事情并且这不是相关的帖子。：）

Answer 2

如果您仅根据客户端代码将其缩小到Reporting Services，我会查看检索您数据的查询/ SP。在我那个时代，我遇到了一些看起来相当无辜的非常讨厌的问题。

Answer 3

我刚做了一些非常讨厌的报道！我不得不在多个表上加入shady标准，每个表包含几百万行。

结束创建一个控制台应用程序，用于前一天每晚进行收集。所有逻辑都过于沉重，因此生成报告只需要太长时间。现在速度不再是问题了。

这取决于报告的类型。这三份报告只需要昨天的数据。但正如奥斯丁所说，查询或其他任何问题通常都是瓶颈。

另一件需要记住的事情是报告在一段时间后“过期”（这是默认设置）。因此，如果您暂时不使用该报告，则生成需要更长的时间。如果你在下一个更快之后再做一次。解决方法是转到Internet Explorer中的报告并单击属性并查看执行和历史记录（可以调整它们以改进报告的呈现）但要小心，但如果数据很关键，您可能会得到旧数据

什么是使Reporting Services更快的通用方法

3 个答案: