性能考虑
报告性能通常被理解为终端用户执行查询时系统生成报告的速度和效率。性能取决于各种因素，包括系统带宽、并发用户数、要显示的数据量等。
当然，其中一些性能因素是“环境的”，也就是说，基本上不受报表开发人员的控制。但是，其他的则不是，聪明的报表开发人员应该意识到这些因素，并利用它们来创建高效执行的报表，并且不会给系统带来不适当的负担。
在进一步阐述主要绩效因素之前，我们建议先了解一些关于报告内部工作和原则的要点。
报告处理阶段
当第一个报表呈现启动时，应用程序将在内存中加载它所依赖的程序集。这可能会导致额外的延迟。您可以将~2s的延迟视为初始加载的正常时间。
处理数据:从数据源获取原始数据后，报告引擎使用它创建OLAP多维数据集。它的维度是根据报告和包含的数据项的组定义构建的。度量值从所有表达式中计算。这对于报告定义中的每个数据源都是重复的。
处理报表项:使用报表定义和已经计算的OLAP多维数据集层次结构，构建报表处理对象树。报表处理树包含所有必需的布局信息，而不考虑页面设置信息。
将报告呈现到所需的媒体，执行分页并计算页面聚合。
环保报告表现因素及建议:
报表处理和呈现是内存密集型操作。从原始数据构造的OLAP多维数据集在报表生命周期期间保存在内存中。这可能是内存不足异常的原因，特别是在呈现报告的进程以32位模式运行时。渲染性能还受到CPU功率和可用内存的影响。显然，硬件越快越好。对于数据和布局密集型的报告，我们建议至少使用一个双核处理器，至少有2gb的RAM。网络流量带宽也会影响性能。
处理大工作量
要在处理包括用户对大型报表的请求在内的大型工作负载时获得最高性能，请执行以下建议。
控制你的报告的大小
您首先需要确定这些报告的目的，以及是否需要一个大的多页报告。如果需要一个大的报告，那么它的使用频率是多少?如果您为用户提供更小的汇总报告，您是否可以减少用户尝试访问这个大的多页报告的频率?大型报表对报表环境有很大的处理负载，因此有必要在个案基础上评估每个报表。
这些大型报表的一些常见问题是，它们包含在报表中没有使用的数据字段，或者它们包含重复的数据集。通常情况下，用户检索到的数据比他们真正需要的要多。要显著减少报告环境上的负载，请创建使用聚合并只包含必要列的摘要报告。
使用Telerik报告REST服务缓存
如果您有不需要实时执行的报表，请将服务ReportSharingTimeout设置为适当的值。更多信息请参见:HTML5报表查看器和报表REST服务万博体育手机版网址
为非浏览器格式交付呈现的报告
为了减少报表环境的负载，您可以使用我们的报表服务器，在非高峰时间调度报表，并在准备好时通过邮件发送，从而避免等待和开箱即用。
开发商控制的性能因素:
PageCountPageCount触发额外的分页传递，该分页传递取决于报表量和复杂性，可能会显著降低呈现速度。如果性能很重要，可以考虑避免使用PageCount对象;
报表项的数量报表项的数量会影响加载时间，就像网页请求的信息越多，加载所需的时间就越长。考虑更改大而慢的报表布局，并使用行动(下钻，钻透)和报表参数(随需应变的数据)。除了对最终用户有利之外，这些特性还使报告更快、更有效，通过只给出所请求数据的当前状态来减轻报告负载;
媒体渲染在处理报表之后，使用各自的呈现扩展在所需的媒体中呈现报表。每个渲染扩展都有它的特性，如果所有的报告都只以一种特定的格式处理，那么尝试添加更多的内存，或者选择不同的格式;
Excel呈现Excel呈现引擎会根据每个项目的坐标和大小创建一个复杂的矩阵，然后创建一个包含许多单元格和行的表，其中一些仅仅用作“间隔符”。这种方法保存了物品的确切位置和大小，但要付出很多计算的代价。当一个报告有大量的项目没有垂直和水平对齐时，结果表是巨大的。将你的物品水平和垂直排列，确保在设计期间没有任何警告标志。虽然在其他格式中，渲染位置和大小与性能无关，但在Excel中，这是至关重要的。水平和垂直对齐的项目越多，Excel渲染引擎创建的虚拟间隔行和单元格就越少;
从数据源检索的数据量如果您的报告显示大量数据，那么从数据源检索数据可能需要很长时间。对于大量的数据源数据，您需要检索最小的可用数据集，以减少网络流量，有效地使用资源并快速呈现报告。可以通过使用应用于报表级数据的选择与应用于数据源的用户选择来实现这一点概述．当数据不需要重新查询时，应用于数据源级别的选择是有效的。当只需要很小范围的数据时，这种方法是有效的。为相同数据的不同视图到数据源的额外行程增加了网络通信成本和呈现报告所需的时间。当在报表级别应用用户选择时，数据被缓存在内存中。当需要相同数据的不同视图且数据不是太大时，这种方法非常有效。这些技术的组合可能是最合适的解决方案。若要在数据库级别上筛选数据并仅获取数据的一个子集，请查看使用参数和数据源对象；
表达式复杂的表达式(特别是有许多报表项的表达式)需要一些时间来求值，而且它们还可能导致速度变慢。将这些表达式替换为用户函数因为用户函数是已经编译好的代码;
子报表项的个数子报告项引用应该单独处理的报告定义。这是一个开销很大的过程，可以通过绑定到相同数据源并具有与子报表报表定义相同布局的Table或List项来避免。如果需要主数据项(报告)数据源中的一些数据用于子数据项数据源参数，则可以利用数据源组件的关系能力如何使用reporttitem。表达式中的DataObject属性文章;
HtmlTextBox项的数量HtmlTextBox内容是用HTML解析器解析的，这是一个消耗资源的过程。当性能很重要时，我们的建议是避免广泛使用这个项目。而不是复杂的文本样式在一个单一的HtmlTextBox，你可以尝试实现所需的布局与多个文本框;
事件用事件中断报表处理是有代价的。而不是考虑使用表达式而且用户函数．如果必须保留事件，请确保事件处理程序中没有消耗时间和资源的操作减慢报表处理。
图表项目的数量旧的表项不使用报告数据引擎，而是使用自己的数据引擎。因此，显示许多图表涉及额外的数据处理。在2013年第一季度，我们介绍了图项目新项目利用优化的报告数据引擎。因此，我们强烈推荐它而不是过时的图表项。如果你必须使用过时的Chart项，请避免使用IntelligentLabels函数;
隐藏的报表项隐藏报表项(将其可见性设置为false)不会阻止报表引擎处理这些项。它需要处理隐藏的项，以便获得报表的其他特性，例如行动，才能正常工作。如果该报表项为数据项它仍然会从数据源检索数据，从而降低总体性能。因此，建议添加服务器端过滤基于控制数据项可见性的相同条件。
有关额外协助
如果您的情况不是上面列出的，或者您已经尝试了所有的建议，但仍然感到渲染缓慢，请打开一个新的支持票请将以下信息发送给我们，以便我们调查您的情况，并检查是什么原因导致您的麻烦:
为什么你认为报告很慢(基准，比较等);
您试图显示的数据/页面数量;
报告布局的复杂性(使用的项目的类型和数量);
呈现报告的机器硬件和软件配置;
您存档的报告文件;
要绑定到的数据源。