维图 影响Web性能的因素：系统配置文档设计层配置和查询设计工作流程

本文档的目的是为 WebI 报表设计者提供一些建议和最佳实践。 多年来，Web 已经发展成为具有许多功能的成熟产品，这给开发文档带来了一些挑战。

良好的执行文档是让用户采用产品的关键因素，因为用户期望快速响应，如果在一定时间内没有得到他们期望的结果，他们会放弃正在进行的任务并寻找替代方案。

WebI文档的设计应该与WebI引擎的能力相匹配，以确保显示出令用户满意的文档。 以下是影响 Web 性能的因素：

系统配置文档设计语义层配置和查询设计工作流程

我们希望本文档能够为您提供这些领域的建议和最佳实践，从而帮助您构建良好的可执行 Web 文档，最终满足您的用户的需求。 注意：提供的建议和最佳实践未指定特定版本，因此本文档中提到的某些功能可能不包含在您正在使用的版本中。

提高网络性能的最佳实践和技术的文档是一个正在进行的项目。 如果您想收到更新通知，请选择文档右上角的“”选项。

如果您对希望添加的某些功能有最佳实践或建议，请通过底部的评论部分告诉我们，我们将评估是否可以包含它们。

这些建议来自 SAP 内部各方，包括：开发、技术支持、服务和产品专家。 非常感谢大家对本文档的投入。

我们还创建了具有相同内容的幻灯片布局。 如果您想向用户演示此主题，您可以在此处找到演示幻灯片： - 最适合 Web

注意：一旦添加其他信息，此 SCN 文档将首先更新。 此后幻灯片布局将定期更新。

注意：本文档与Web 文档的提示包含相同的内容。 尽管某些内容是重复的，但这两个文档都包含可以帮助您优化 WebI 报告的提示和最佳实践。 本文档是最佳实践的概述，上面的文档将提供有关如何优化 Web 文档性能的更多详细信息。

SAP 社区网络的其他参考资料

除了此最佳实践文档之外，以下附加文件可能有助于提高 WebI 报告的性能：

提高 Web 性能以实现快速运行的技巧

每个人都讨厌等待应用程序加载。 近几个月发布的一些 Java 更新可能会严重影响 Web（Rich）加载时间。 该领域经常出现以下三个问题：

在线证书吊销检查导致延迟 新的 JRE 安全更改导致问题和延迟 包含 60 多个 JAR 文件导致许多安全检查

在线证书吊销检查

新的 JRE 版本（1.7.0_25 及更高版本）会自动在线检查已吊销的证书。 它将对 a 中的每个 JAR 文件运行此撤消检查。 在BI4.0的初始版本中，这些包括60多个JAR文件。

此外，网络连接速度也是影响加载时间的主要因素。 当网络连接速度较慢时，需要检查 60 多个 JAR 文件是否已吊销证书，这可能会增加几分钟的加载时间。

提高在线证书吊销检查性能的提示：

默认情况下，Java运行时环境通过两种方法验证证书吊销，即“证书吊销列表（CRL）”和“在线证书状态协议（OCSP）”。 为了减少慢速互联网连接上的加载时间，建议将 Java 控制面板的默认设置更改为仅使用证书吊销列表 (CRL)，或者选择“不检查”选项（如果公司安全准则允许）。

欲了解更多详情，请参阅 WIKI 和

JRE 安全更改

我们在加强安全要求方面投入了大量精力。 下一步，相比SAP的补丁周期，新的JRE版本的发布将会更加频繁。

一些常见问题和解决方案可以在这里找到：Web 和 JRE 已知

尺寸

随着SAP BI4.0的推出，Web有了一个全新的架构。 在早期版本中，Web 存在于 jar 文件 (.jar) 中。 随着BI4.0新架构的引入，这已经被许多独立的jar文件（60+）所取代，使得开发和升级变得更加容易。 然而，由于 Java 安全更新，加载过程中的性能有所下降。 SAP 决定从 BI4.1 SP03 开始​​恢复为单个文件（.jar 和 .jar 作为配套资源文件）。 这使得 JRE 只剩下 1 项安全检查和 1 项缓存检查。

为了受益于改进的 Web 性能，建议将 BI 产品升级到 BI4.1 SP03 或更高版本。

注意：这是一个44M的JAR文件。 首次加载可能需要一些时间，具体取决于网络性能。 当有新的服务版本或补丁升级时，首次加载也会很慢。

额外的 JRE

前面提到的JAVA设置中，可以利用附件的重要性来进一步提高Web Java（Rich）的性能

确保启用 JRE 缓存 确保使用 JAVA 下一代产品插件

可以使用的附加组件的完整列表可以在这里找到：Tips For Fine For The Webi Rich (Java Panel) - In...

一些潜在的瓶颈和位置可以在这里找到：

避免“巨型”文档

太大的文档会浪费大量时间。 如果一个大文档只有 10-20% 有用，那么 89-90% 就被浪费了。 在这种情况下，强烈建议避免使用大文档。

避免在单个文档中创建多个报告（选项卡）

1. 一份文件包含10份报告是合理的

2.一份文件中的报告不超过20份

2. 不要尝试考虑所有场景，而要关注特定场景

1、一个文档包含5万行数据是合理的

2.不要超过行数据

3. 如果文档没有要求，请勿添加其他数据提供者。

1. 5个数据提供者合理

2.一份文件中的数据提供者不得超过15个

为了提高运行时间和分析速度，请创建适合特定业务需求的较小文档。 从特定的业务需求开始，并根据该需求构建文档。 通过创建更小的、可重复使用的文档，您将：

使用报告链接

考虑使用小文档并链接它们而不是大文档。 使用该功能，您可以链接多个文档并从一个文档跳转到另一个文档。 从报告中选择的值和结果可以作为提示或过滤器输入到目标文件中，使整个逻辑文档链精简。

为了更方便地使用，超链接向导在 Web HTML 设计模式下可用。 使用超链接向导，可以通过用户界面（而不是编码）轻松定义 URL 的逻辑。

在某些情况下，利用报表链接（）将导致更长的设计时间，但最终用户将对其良好的性能感到满意。

报告设计最佳实践限制了数据提供者的数量

最佳实践是每个文档的数据提供者不超过 15 个

使用数据仓库集成资源和 ETL 工具生成更好的报告源是一种很好的做法。

检索聚合数据而不是在文档中进行聚合

最佳实践是从数据源获取尽可能多的预聚合数据并将其直接提供给用户。 在需要聚合时检索详细数据被认为是不好的做法。 尽管网络具有强大的数据聚合能力，但数据源在处理数据聚合方面更有效。

如果无法预先计算所需的聚合，请在查询定义中使用聚合命令（请参阅语义层最佳实践）。 这将要求源数据库在将数据发送到 Web 处理引擎之前聚合数据。

不要禁用网络缓存

Web 对于已查看的文档有强大的缓存机制。 使用缓存可以加快文档的加载时间。 但是，有些 Web 功能会阻止使用缓存。 这些功能是：

使用这些函数将在每次请求时重新生成文档，从而无法利用缓存的优势。

避免自动调整

尽管自动调整对于单元格、表格、交叉表和图形来说是一个很好的选择，可以自动调整大小以适应内容。 但它也会在导航时强制进行文档计算。 这将使浏览报告的速度变慢。 最大的影响是在大型报表中从最后一页跳转到第一页会非常慢。

避免高维图

从 BI4.x 开始，添加了新的图表引擎：通用视觉对象模型 (CVOM)。 该引擎包含在自适应处理服务器 (APS) 中，称为可视化服务。

CVOM 允许您在 Web 文档中制作漂亮的图表。 但是，您应该创建许多小图，而不是创建一个包含大量数据的大图。 使用更小、更详细的图表会更有效。

避免嵌套部分

使用嵌套部分可能会导致性能下降。 当使用诸如“如果以下为空则隐藏部分”之类的条件时尤其如此。

向下钻取报表时使用查询钻取

在文档属性中，有一个“使用查询钻取”选项。 查询钻取功能利用底层数据库的性能。 如果未选中查询钻取，则查询会将越来越多的数据加载到文档中。 启用此功能后，钻取请求会修改查询并从数据库中检索新数据。 通过这种方法，本地存储的用于钻取的数据量可以提高文档性能。

“分析范围”的使用限制

分析范围可用于具有简单演练会话的文档。 但是，一旦启用并定义了分析范围，将从数据库中检索其他数据并将其存储在文档的多维数据集中。 加载的数据越多，对性能的影响就越大。

除了使用范围/练习之外，在获取详细数据时还可以使用报告链接作为替代方法。 报告链接的优点是详细报告仅获取所需的数据（而不是整体使用向下钻取）

提示：在 BI 启动板 Web 的首选项中，您可以选择是否在钻取需要更多数据时进行提示。

公式的最佳实践

Web公式引擎很强大，但取决于公式的逻辑。 公式中的某些语句始终会计算整个数据集，但是，将计算分解为多个步骤（因式分解）将使计算引擎工作得更快。 下面记录的是计算引擎的已知示例。

= [] + []

= [] + []

相比于：

= [] + [] + []

通过将其分解为步骤，计算引擎可以更快地处理结果。

语义层最佳实践

创建可执行的 WebI 文档取决于底层。 某些语义层的默认设置并不适合实际使用，建议更改它们。

构建精益查询

创建新文档时，会在初始查询中检索许多度量和维度。 在后续的构建中，添加了越来越多的对象，导致大量的查询。 这违背了语义层的基本原则，因为它的目的是简化数据查询。

在查询中包含许多对象来获取大量信息可能对开发人员有用，但对最终用户来说却很不方便。

请按照以下步骤逐步创建文档：

从文档的需求开始，并为该特定需求创建查询。

-不要添加不必要的尺寸、细节或措施

- 如果您不确切知道需要哪些对象，请制作一个简单的报告，而不是稍后删除对象。

2. 从查询中删除未使用的对象。

报告完成后，验证查询中所需的所有对象是否已在文档中实际使用。 如果没有，请删除未使用的对象。

3.删除未使用的局部变量

移动未使用的对象后，删除文档中未使用的所有变量。 即使不使用该变量，计算引擎也会对其进行计算。

摘要： 创建查询时，仅包含文档中使用的对象。

优化数组获取大小

语义层的默认设置是数组获取大小（在连接中定义）。 数组获取大小设置一次从数据库获取的最大行数。 调整到合适的大小可以显着提高性能。

内部测试已经证明，增加数组获取大小（以前默认 = 10，IDT 设置为“优化模式”）将提高基于此创建的报告的整体性能。

在内部测试期间，我们从数据库中提取行到报告中，并记录从数据库中提取行所花费的时间。

在我们的例子中，将数组获取大小增加到 1000（每次获取的行数），将数据从数据库加载到报告引擎需要 18 秒。

不建议盲目采用我们内部测试的结果，因为影响您具体情况的因素有很多（例如网络）。 推荐的方法是使用许多不同的设置进行多次测试，以定义最佳的数组提取大小。

随着 BI4.x 的引入，每个新创建的连接中的数组获取大小默认设置为“最佳”。 这并不总是最佳设置，因为它基于有限的测试。 您可以使用“”参数禁用此设置。 为了覆盖最佳值，必须在工具 (UDT) 或工具 (IDT) 中将参数设置为“是”。

更详细的参数信息请参考工具指南

使用查询过滤器代替报告过滤器

通常，报表过滤器为报表用户提供快速呈现特定数据集的灵活性。 但是，使用报表过滤器可能会导致数据增加到一定程度后性能下降。 如果您要使用报表过滤器来过滤大量数据，建议调整报表查询并使用查询过滤器。

使用查询过滤器将减少总体报告运行时间，因为它显然会检索更少的数据。

启用查询剥离

查询剥离是 BI4.x 中的一项新功能，可帮助您从查询中删除未使用的对象。 通过查询剥离，查询引擎会在刷新之前验证查询中的所有对象是否已在文档中使用。 如果不使用对象，它们将从发送到数据库的查询中删除（注意，它们不会在查询面板中删除）

从 BI4.1 SP3 开始，查询剥离也可用于关系数据库。 以前，查询剥离仅适用于基于 BICS 连接 (BW) 创建的文档。

对于使用 BICS 连接的文档，默认情况下启用查询剥离，但必须手动设置其他连接类型。

对于基于关系数据库创建的文档，必须设置以下参数：

在业务层允许查询剥离 (IDT) 在 Webi 文档的查询属性中启用查询剥离 在 Webi 文档的文档属性中启用查询剥离

注意：该参数仅优化GROUP BY子句，不会修改SQL语句的表链接或其他子句。

仅在需要时合并维度

默认情况下，如果两个数据提供者包含相同的对象，BI4.x web 将创建合并维度。 但如果最终报表不需要显示合并数据，建议不要合并维度。

合并维度会影响性能，因为其逻辑必须在计算引擎内应用以创建合并的数据集。 拆分不必要的维度可以提高性能。

了解架构差异

SAP BI4.x 与以前的版本不同。 尽管从技术上讲，它看起来像相同的平台，但背后却有很大的变化。

主要变化是 BI4.x 是一个完全 64 位服务器架构。 以前的版本（XI3.x 及更早版本）是 32 位架构，因此有很多限制。 使用64位架构的主要优点是单个进程可以请求超过2GB的内存。

此外，BI平台的后端服务“工作”方式也发生了变化。 在XI3x平台上，Web处理服务器将处理所有请求：从生成SQL语句到渲染报告和图表……在BI4.x上，这些任务已被分配给各种“通用且共享”的服务来处理。

对于Web，可以使用以下BI平台服务（根据具体情况）

Web 处理服务器可视化服务 (APS) -> 生成图形 DSL- 服务 (APS) -> 创建新的语义层和 BICS 连接数据联合服务 (APS) -> 多源连接服务器（64 位） -> 3 -层连接方式连接服务器（32位）->二层连接方式安全标记服务（APS）->SSO会话WebI监控服务（APS）->客户端监控Web应用服务器->页面渲染。。管理服务->身份验证文件存储服务->文件检索/实例存储发布服务（APS）......

强烈建议您了解 BI4.x 的技术图表和 BI4x Web 流程。 下面的处理流程至少需要了解：

注意：这些程序目前正在修订以纳入最新的更新。 请继续关注更新版本！

使用计划功能

为什么使用计划

最佳实践是，任何刷新时间超过 5 分钟的报告都应进行安排。 利用BI平台的调度功能，可以利用Web处理服务器的缓存机制来加快报表处理速度。 在计划设置中，当计划为Web格式时，您可以选择计划时用于预加载缓存的格式（包括XLS和PDF格式）。

建议让用户使用调度功能，而不是让技术人员处理所有调度。

对服务器进行分段以获得最佳性能

任何新安装的 BI4.x 都不会进行分区和配置以供生产使用。 随着 BI4.x 堆栈及其 64 位架构的变化，Web 服务可以处理更多任务（如果正确分区和配置）。 由于 64 位，Web 处理服务器的内存分配没有限制。 因此，不再需要同一台计算机上的其他 Web 处理服务器（以平衡内存需求）。

对于 BI4x，建议每台计算机仅配备一个 Web 处理服务器。 仅当达到限制/或希望进一步平衡负载时，建议添加额外的网络

进程服务器。 但是，不建议在一台计算机上添加 2 个以上的 Web 处理服务器。 因为在新的架构下，WebI可以抢占更多的内存。 如果有多个Web

全部在一台机器上处理服务器可能会损害系统稳定性。

在更改后的架构中，Web 处理服务器还将工作分配给其他服务：

除了正确分段您的 Web 处理服务器之外，您还应该对其所依赖的服务进行分段和配置。要了解有关 Web 或自适应处理服务器 (APS) 分段的更多信息，请参阅 BI 页面了解详细信息

位置有很大不同

理想情况下，您的（Web）处理层应该靠近数据库。 处理层向数据库请求数据，并通过网络层获取数据。 如果处理层和数据库之间的距离很远，可能会出现许多性能问题。 即使您的处理层靠近数据库，也强烈建议使用快速网络 (1 Gbps+)。 在处理层和数据库之间添加的任何网络层都会增加额外的步骤，从而导致延迟。 要了解处理层和数据库需要多长时间，建议定期检查网络性能和任何潜在瓶颈。

使用本地存储

Web 处理服务器可以使用大型缓存，全部存储在磁盘上。 网络

将处理服务器缓存在本地磁盘上（最好是快速的，例如 SSD 或 10+ K SCSI）将提高性能，因为本地存储在输入/输出方面比网络存储快得多。 如果缓存目录位于网络共享/NAS/SAN 上，建议定期检查网络性能和任何潜在瓶颈。

CPU很重要

虽然BI4x的分段工作是在APS中进行的，但有一个事实是CPU加速确实与Web的整体性能密切相关。 这在较旧的硬件上更相关。 即使你有128个CPU，也会导致报告很慢。 Web 需要大量计算，CPU 越快，引擎就越快。