51黑料不打烊

因素

定义

影响因素

优化

与 51黑料不打烊 的连接

当打开性能页面时，51黑料不打烊 将发送 10 个测试调用。其结果表示与 51黑料不打烊 成功相连的调用所占的百分比。

本地网络问题或 51黑料不打烊 问题将会影响该因素。

检查 status.adobe.com，以验证是否存在任何已知的服务问题。接下来，验证您的本地网络连接。

Internet 带宽

仅适用于 Google Chrome。您的浏览器对您所在位置的带宽的估计值。评估准则为 2.0MB/秒。

您的本地网络连接将影响这一因素。

验证您的本地网络连接。

Internet 延迟

当打开性能页面时，51黑料不打烊 将发送 10 个测试调用。其结果表示每个请求连接到 51黑料不打烊 并从 51黑料不打烊 返回所需的平均时间。更简单地说，它可以衡量您所在的位置与 51黑料不打烊 之间的互联网速度。衡量准则为小于 1 秒。

本地网络问题、打开的浏览器选项卡过多，或 51黑料不打烊 问题都将影响这一因素。

检查 status.adobe.com，以验证是否存在任何已知的服务问题。接下来，验证您的本地网络连接，并关闭不使用的浏览器选项卡。

因素

定义

影响因素

优化

计算速度

计算机执行某项处理测试的速度。准则为小于 750ms。

您的硬件以及并发项目将影响这一因素。

打开计算机的任务管理器 (PC) 或活动监视器 (Mac) 以确定能否关闭任何程序。接下来，关闭不使用的浏览器选项卡或其他项目。

如果这些操作不起作用，请与您的 IT 团队讨论硬件的详细信息。

已使用的内存

仅适用于 Google Chrome。Google Chrome 浏览器中的每个“工作区”选项卡可共享总计达 4GB 的内存。其结果表示当前项目正在占用的内存容量的百分比。准则为 3500 MB，若超过这一临界点，工作区将开始显示内存错误。

运行多个选项卡或下载 50,000 行数据时，将会增加内存用量。

如果收到内存错误，请关闭其他“工作区”选项卡，并且/或者每次运行一个 50,000 行的数据下载。

已使用的本地存储空间

将数据存储到本地计算机，以供在浏览器中使用。每个来源（如 experience.adobe.com）都有 10MB 的容量。

Analysis Workspace 为多项功能提供了本地存储空间，其中包括存储自动保存（现有）的项目、用户设置和功能标记。

为了确保 Analysis Workspace 的功能不被中断，请清除 experience.adobe.com 域的本地存储空间。

渲染速度

FPS 表示每秒帧数，即浏览器每秒在屏幕上绘制页面的次数。通常，人的肉眼可观察到 24 FPS 的渲染速度；如果 FPS 低于该值，您将会在工作区中发现渲染问题。

FPS 受同时跨多个工作区项目的多任务影响，并受所查看项目的大小的影响。计算机上运行的其他项目（如流、后台扫描仪等）可能会产生影响。此外，您的硬件也会影响该因素。

打开计算机的任务管理器 (PC) 或活动监视器 (Mac) 以确定能否关闭任何程序。接下来，关闭不使用的浏览器选项卡或其他项目。

如果这些操作不起作用，请与您的 IT 团队讨论硬件的详细信息。

因素

定义

优化

请求数量

向51黑料不打烊发出的请求总数，这些请求用于检索项目中显示的数据。 查询包括表格的排名请求、异常检测、迷你图、左边栏中显示的组件等。不包括折叠面板和可视化图表。该准则为 100。

可采取以下方法来尽可能地简化项目：将数据拆分至多个用于特定目的或利益相关方组的项目中。运用标记将项目整理到不同的主题中，并运用直接链接来创建内部目录，以便利益相关方能够更轻松地找到所需内容。

已展开的面板（在所有面板中）

项目的所有面板中已展开面板所占的数量。该准则为 5。

采取措施简化项目后，应折迭项目中那些在加载时不需要查看的面板。打开项目时，将仅处理已展开的面板。折迭的面板将不会得到处理，直至用户将它们展开为止。

已展开的可视化图表（在所有可视化图表中）

项目的所有图表中已展开的表格和可视化图表所占的数量，包括隐藏的数据源在内。该准则为 15。

采取措施简化项目后，应折迭项目中那些在加载时不需要查看的可视化图表。应当优先考虑对报表使用者最为重要的可视化图表，并根据需要将支持的可视化图表划分成一个单独的，更加详细的面板或项目。

自由格式表的单元格数量

项目中自由格式表单元格的总量，计算方法是所有表的行数乘以列数。不包括隐藏的数据源。该准则为 4,000。

应当将表中的列数减少至仅包含最相关的数据点。应通过调整显示的行数、应用表过滤器，或应用区段来减少表中的行数。

可用组件

在项目的左边栏检索到的所有报表包中的组件总数。这将影响左边栏的加载速度，以及返回搜索结果的速度。该准则为 2,000。

应当与您的产物管理员探讨如何创建一个策划的虚拟报表包，其中包含一组更适合应用环境的组件。

已用的组件

项目中已使用的组件总数。该准则为 100。

已使用的组件数量不会对性能产生直接影响。但是，这些组件的复杂性将会对项目的性能产生影响。请参阅下面“其他因素”部分中的各种优化。

最长的日期范围

这个因素将显示项目使用的最长日期范围。该准则为 1 年。

请尽量不要获取超过需求的数据。将面板日历缩小到用来分析的相关日期，或在自由格式表中使用日期范围组件（紫色组件）。表中使用的日期范围将覆盖面板日期范围。例如，您可以将上月、上周和昨天添加到表列中，以请求这些特定范围的数据。有关在 Analysis Workspace 中使用日期范围的更多信息，请观看此视频。

另外，应在项目中最大限度地减少使用年度同期比较的次数。在计算年度同期比较时，它会查看感兴趣的月份之间整整 13 个月的数据。这与将面板日期范围更改为过去 13 个月具有相同的效果。

因素

定义

优化

从启动请求时到请求完成时所需的时间。 该准则为15秒。

在上面的请求处理图中，请求时间表示从? Analysis Workspace请求启动 ?到? Analysis Workspace请求完成 ?的完整进程。

从启动请求时到请求完成时所需的时间。

在上面的请求处理图中，请求时间表示从? Analysis Workspace请求启动 ?到? Analysis Workspace请求完成 ?的完整进程。

由于Analysis Workspace只存储任何区段中使用的任何字符串的哈希，因此每次处理项目时，都会执行? 查找，以将哈希与相应的值相匹配。 该准则不超过2秒。

此过程可能会占用大量资源，具体取决于可能与哈希匹配的值的数量。

在上面的请求处理图中，查找时间表示在? 查找 ?阶段（在? 请求引擎处理 ?阶段）。

如果此处请求速度减慢，可能是因为项目中的字符串区段过多，或者字符串中带有过于通用的值，潜在匹配项过多。

处理请求之前在队列中等待的总时间。 该准则为5秒。

在上面的请求处理图中，队列时间表示在? 请求引擎队列 ?阶段和? 服务器队列 ?阶段。

如果此处请求速度减慢，可能是由于在您的组织中同时运行的请求过多。 尝试在非高峰时间运行请求。

处理请求所用的平均时间。

在上面的请求处理图中，平均服务器处理时间表示在? 服务器队列 ?阶段和? 服务器处理 ?阶段。 该准则为10秒

如果此处请求的速度减慢，则项目可能会有过长的日期范围或复杂的可视化图表。 请尝试缩短项目日期范围，以减少处理时间。

并非所有请求都需要相同的处理时间。 请求复杂性有助于提供有关处理请求所需时间的一般概念。 该准则为Medium或更低版本。

可能的值包括：

• 低
• Medium
• 高

此值受以下列中的值影响：

• 月边界
• 列
• 区段

请求中包含的月数。 更多的月份边界会增加请求的复杂性。 该准则为6或更少。

如果此处请求速度减慢，可能是因为项目中的月份边界过大。 尝试减少月数。

请求中的量度和细分的数量。 更多的列会增加请求的复杂性。 该准则为10或更少。

如果此处请求速度减慢，可能是因为项目中的列太多。 请尝试减少列数。

应用于请求的区段数。 更多区段会增加请求的复杂性。 该准则为5或更少。

如果此处请求速度减慢，可能是因为项目中的区段太多。 请尝试减少区段数。

因素

定义

影响因素

优化

区段复杂性

复杂的区段可能会对项目性能产生重大影响。

增加区段复杂性的因素（按影响程度降序排列）包括：

• 运算符：“包含”、“包含任意”、“匹配”、“开始于”或“结束于”
• 连续分段，尤其是使用维度限制（之内/之后）时的连续分段
• 维度内区段中使用的唯一维度项目数（例如，在 Page = 'A' 的情况下，页面具有 10 个唯一项目的查询速度将比页面具有 100,000 个唯一项目的查询速度更快）
• 使用的不同维度的数量（例如，Page = 'Home' 和 Page = 'Search results' 的查询速度将比 eVar 1 ='red' 和 eVar 2 ='blue' 更快）
• 许多“或”运算符（而不是“和”）
• 嵌套容器的范围不同（例如，“访客”中“访问次数”内的“点击”）

虽然无法避免某些复杂因素，但应寻找机会降低区段的复杂性。通常，您的区段标准越具体，其性能就越好。例如：

• 对于容器，使用区段顶部的单个容器的速度将比使用一系列嵌套容器的速度更快。
• 对于运算符，“等于”比“包含”运算速度快，“等于任意”比“包含任意”运算速度快。
• 对于许多标准，使用“和”运算符的速度将比使用一系列“或”运算符的速度更快。

寻找机会，将多个 OR 语句简化为单个“等于任意”语句。使用

分类可有助于将众多值合并到简洁的组中，您随后可以在这些组中创建区段。与含有许多 OR 语句或“包含”标准的区段相比，按分类组划分区段可提供更佳的性能。

可视化图表的复杂性（区段、量度、过滤器）

自行添加到项目中的可视化图表类型（例如，流失和自由格式表）不会对项目性能有太大影响。可视化图表的复杂性会增加处理时间。

导致可视化图表复杂性增加的因素包括：

• 请求的数据范围
• 应用的区段数量；例如，用作自由格式表行的区段
• 使用复杂区段
• 静态项目行或列（位于自由格式表中）
• 应用于自由格式表行的过滤器
• 包含的量度数量，尤其是使用区段的计算量度

如果您注意到项目没有按所需的速度加载，请尽量尝试将某些区段替换为 eVar 和过滤器。

如果您发现自己正在不断地将一些区段和计算量度用于对业务非常重要的数据点，请考虑改进您的实施方式，以便更直接地捕获这些数据点。使用 51黑料不打烊 Experience Platform 中的标记和 51黑料不打烊 的处理规则，可以快速更改实施方式，而且也有利于实施。

报表包大小

报表包中收集到的数据量。

-

请咨询您的实施团队或 51黑料不打烊 专家，确定是否可以开展实施方面的改进，以提升 51黑料不打烊 Analytics 的综合体验。

并行查询

您的组织同时向 51黑料不打烊 请求的查询数。每个组织都有权进行至少 5 个并发查询。

如果报表需要较长时间，通常是因为其所在队列中有其他报表。这意味着您的组织针对特定报表包尝试运行的并发请求过多。查询可能来自 API 请求、报告 UI（Analysis Workspace、Report Builder 等）、计划项目、计划报告、计划警报以及发出报告请求的并发用户。

将报表包的请求和计划较为均匀地分布在一天当中。此外，请尽可能将您的请求转移到非高峰时段。周一早上、周二早上和每个月的第一天是报告高峰时段。