Knowledge :000213798

描述问题:

您或您的用户要么无法连接Salesforce，要么您的连接比正常速度慢得多。

这些问题可能是最难解决的，因为它们会使您的团队陷入停顿。

有时，它们可能是由一些看似无害的事情引起的，比如安装一个新的包、实现一个新的共享规则或启用一个特性。

然而，到目前为止，这些问题最常见的原因是您的用户和Salesforce应用程序之间的联系——Internet服务提供商(ISP)和网络。

ISP和网络问题将是本文的重点，其最终目标是为您提供有效地解决此类问题的工具，以推动快速的解决方案。

解决办法

故障排除:

1。检查Trust

在这些情况下，首先要做的是检查status.salesforce.com/status。在这个页面上，我们报告实例的可用性和性能问题。在上图中，如果我们与ISP合作解决任何网络问题，我们也会偶尔发布一般的状态信息。

2。问你的同事。

检查你的整个团队是否也正在经历同样的绩效水平，他们是否已经找到了缓解的方法。例如，您总是使用硬线连接，但是您有一个使用WiFi的同事，他们没有遇到这个问题。此外，如果您的公司有多个办公室或远程员工，请尝试与他们核实——他们看到更好的表现了吗?您的团队在所有的组织(包括沙箱)中都有相同的性能体验吗?如果这些场景中的任何一种都适用于此问题，那么您很可能遇到的是网络问题，而不是Salesforce特有的问题。

3. 运行Ping到Salesforce

从基于Windows系统的系统点击开始按钮，在搜索栏中键入“cmd”。顶部的结果应该是一个名为“cmd”的条目——点击这个。在生成的控制台窗口中，键入

ping - n 100(实例).salesforce.com

你的具体实例在哪里?例如:如果你在na5上，它会在哪里

ping - n 100 na5.salesforce.com。

您将开始看到在屏幕上运行的文本行。根据您到Salesforce的具体路线，这可能需要几分钟才能完成。这个结果的输出将类似于na17.salesforce.com的ping测试:

 

这些结果表明，当时我与指定的实例有很好的连接。误差的迹象包括:

包丢失大于10%(我的包显示为零丢失)

大量的往返时间。虽然时间之间的差异约为100ms是很常见的，但如果您的往返时间平均为105ms，最大为500ms，则表明您可能存在一些网络问题。

4。运行一个Traceroute到Salesforce

traceroute会告诉我们你的流量是如何到达Salesforce的。它还将有助于确定可能发生的问题。要运行traceroute，请返回命令提示符并输入

路径跟踪程序(实例).salesforce.com

下面是我跑到我们的北美实例NA17 (tracert na17.salesforce.com)的traceroute:

 

要阅读这篇文章，从第一行开始——这是你的流量离开你的电脑后的第一个停止。可能是10.X.X.X。或者是192.168.X.X 数量。这些都是为私有网络所保留的，在追踪器的后面也相当常见。在这条路线的后面，他们只是表示在退出之前，通信正在通过ISP的内部网络。

你看到的3个数字是到达特定跳点的时间。需要注意的是，这些数字并不代表当前跳转和前一个跳转之间的时间差异，而是代表该跳转之前的累计时间。当你观察一个traceroute时，你在寻找第一个点，在这个点上，时间之间的差异非常大(例如:50 ms 283 ms, 29 ms)，或者对于那些始终比前一个跳高得多的时间。您也可以将“*”视为一个条目。这表明服务器没有收到回复。这些未必是问题的征兆，尤其是当你接触到Salesforce的时候。出于安全原因，某些网络不会对traceroutes中使用的包进行应答。一旦进入数据中心，Salesforce也会这样做。如果您看到一个跳有一个超时，那么只要事情看起来正常，这可能不是问题。需要注意的是，您的“正常”traceroute和ping结果将根据您的系统和数据中心的地理位置而变化。例如，如果你在澳大利亚，正在连接美国东部的数据中心，250-300ms的往返时间并不是不寻常的。然而，从澳大利亚到东京数据中心的300毫秒的往返时间是不寻常的。

5。查找奇怪的路由决策和节点特定的问题。

ISP经常更新他们的网络，比如调整路由选择和增加新线路。他们这样做是为了保持网络的健康，并试图优化某些流量模式。有时，这些更改可以通过不太理想的路径将请求路由到Salesforce。例如，如果您正在从加州访问一个基于北美的Salesforce实例，但是正在通过新加坡进行路由，然后返回应用程序，那么您肯定会看到加载时间增加。这将在ping和traceroute的结果中显示为一致的高往返时间，+300 ms，每个跳的时间之间的差异很小，并且接近0个包丢失。您还可以看到在一跳的跨度中有两个100ms以上的大跳转。这是洲际跳跃(intercontinental hop)的典型行为，或者你的交通跨越了显著的地理距离。

如果你是建立在同一地区数据中心(APXX纳克萨玛斯实例的北美,亚洲,欧洲/非洲EUXX)和你碰巧注意到一个大跳在你的路由跟踪,你可以去[IP地址].ipaddress.com找到特效IP地址的地理位置跳在哪里发生。

如果您注意到这类问题，请联系您的ISP，因为他们控制您的请求到Salesforce的路径。

另一个网络路由问题的例子如下:

 

在这个traceroute中，我们可以看到5 个* ' s在第6和第7行。我们可以看到的另一件事是，第5和第7行都属于第3级通信公司，我们正在跨大西洋航行。因为这是一次横跨大西洋的跳跃，我们不需要担心时间增加了大约75毫秒。我们应该关注的是，我们的跨大西洋的跳跃是不一致的。如果这与第3步中的ping绑定，您可能会看到包丢失。在这种情况下，你应该联系你的ISP，让他们知道你找到了什么。您的ISP应该能够修改您的流量使用不同的跨大西洋链接的路径，或者至少联系他们的合作伙伴(本例为第3级)以进一步研究这个问题。

6。联系销售团队支持

如果您仍然无法确定任何网络问题，请将您使用上述步骤收集的所有信息发送给Salesforce support。我们将密切关注您的组织，并与我们的网络运营团队进行评估。

在本指南中，您可以了解Force.com的性能分析工具及其相关的方法，这些工具是通过来自salesforce.com客户支持和我们自己的工程团队的建议了解的。例如，在使用功能单元测试来验证您的应用程序是否按设计工作时，salesforce.com建议使用性能分析，这样您的应用程序就可以处理数据量和复杂的共享配置，这些配置可能随组织的大小和成功而增长。如果您是Force.com的架构师或开发人员，或者是经验丰富的Salesforce管理员，那么这些技巧可以帮助您正确地编写应用程序代码，并使其为用户提供的价值最大化。

注意:本指南适用于具有编程顶点和Visualforce经验，并对Force.com多租户体系结构有基本了解的读者。

性能分析工具和资源的概述

我们鼓励您熟悉这些性能分析工具和资源，使用这些简短的描述和与上述描述的链接相关的更全面的资源。

开发人员控制台

开发人员控制台是您可以用来在Salesforce组织中创建、调试和测试应用程序的工具的集合。Developer Console提供了许多用于分析性能的面板。根据详细的执行日志(您可以通过使用与logs选项卡关联的日志检查器来打开日志)，您可以查看总体请求的图形时间线、操作的聚合性能、调控器限制的统计信息，以及对已执行单元的深入分析。在本指南中，我们使用Developer Console作为引导您完成性能分析过程的主要工具。

调试日志

调试日志记录执行事务时发生的数据库操作、系统进程和错误。每次用户执行包含在筛选条件中的事务时，系统都会为用户生成一个调试日志。可以调整每个日志包含的细节级别。虽然调试日志文件显示为纯文本，但是很难解释它们的原始日志行。本指南向您展示了如何使用开发人员控制台在性能分析时有效地分析这些行。

工作台

Workbench是一个强大的、基于web的工具套件，可以从开发人员社区获得。为管理员和开发人员设计的这个工具允许您在salesforce.com组织的Web浏览器界面中直接描述、查询、操作和迁移数据和元数据。Workbench还为Force.com api的测试和故障排除提供了许多高级特性。本指南使用Workbench演示如何轻松地通过API运行查询并获得性能分析所需的信息。

架构师核心资源

开发人员Force的架构核心资源页面是在Force.com平台上构建声音实现的最佳实践库。在这个页面上，您可以找到许多与性能优化相关的白皮书、网络研讨会和博客文章的链接。这些资源可以帮助您了解在对应用程序进行性能分析时应该寻找什么，以及如何应用最佳实践来克服与性能相关的挑战。对该内容的引用贯穿本指南。

性能分析:方法论

性能分析任务的一个典型的高级流程是这样的。

• 定义任务的范围。将业务场景分为操作、功能或简单地按页面划分。
• 对于每个任务，度量应用程序的性能(例如，Visualforce页面)并识别潜在的瓶颈。
• 识别并解决瓶颈的根本原因。
• 比较结果并重复步骤1、2和3，直到您消除瓶颈或最小化它们的影响。
• 使用更大的数据量和具有不同共享设置的用户迭代性能分析步骤，以便您能够尽可能全面地评估性能影响。

使用调试日志和开发人员控制台

要在Force.com平台上开始性能分析，您需要:

• 启用系统管理员配置文件和开发模式的用户。如果您还没有使用该概要文件的用户，请管理员在自己的Developer Edition组织中免费创建一个或创建一个。
• 将实际使用该应用程序的非管理员Salesforce用户

为了说明分析方法，并避免过多地关注如何解决性能较差的代码，我们来看一个非常简单的场景。

注意:我们假设您已经使用了通用的Web分析工具，如Chrome开发工具、Firebug或Fiddler来识别网络问题和资源优化机会。

下面的基本Visualforce页面显示总销售额和活动销售订单的数量，这两个都是根据它们的机会阶段名称进行分组的。

 

如果您想使用自己的Developer Edition或沙箱组织来遵循本指南中所示的步骤，请使用下面的示例代码，这应该是开箱即用的。如果您是Visualforce新手，请从Visualforce开发人员指南和Visualforce工作簿开始。

Visualforce page source

 

Apex controller source

 

在开发人员控制台中查看Visualforce页面调试日志

尽管可以使用开发人员控制台运行和调试匿名Apex的日志，但不能使用它直接呈现和收集Visualforce页面的调试日志。在跳转到开发人员控制台之前，您必须首先收集性能分析所需的调试信息。如果您的页面中有多个Visualforce组件，那么您可能希望将它们分开并逐个配置它们，除非它们具有依赖关系并影响彼此的性能。

步骤1:设置两个用户。

要获取Visualforce页面的日志，您必须使用两个用户:一个管理员用户来设置和分析调试日志，另一个非管理员用户来访问Visualforce页面。让测试用户设置适当的权限和共享配置，以便您以后可以访问Visualforce页面。从单独的浏览器中，使用管理员用户为测试用户启用调试日志。

提示:通过选择适当的日志级别来设置调试日志过滤器，这样您就可以专注于与应用程序所做的工作和您想要配置的内容相关的领域。这里有一个示例设置配置，可以用于此场景。

 

步骤2:执行你的Visualforce请求。

通过测试用户，通过访问Visualforce页面并完成您想要配置的任何操作来执行请求。

步骤3:打开测试用户的日志。

提示:要查看新日志，请打开日志、测试和问题面板并单击logs选项卡。找到您的日志并双击该行，将日志加载到开发人员控制台。

步骤4:禁用调试日志。

在收集您需要的信息之后，总是停止保留调试日志。如果您让调试日志继续运行，当您达到组织范围内的50mb调试日志限制时，它们可能会覆盖其他重要的日志。此外，每个用户最多只能收集20个调试日志。一旦达到这个限制，就必须为用户重置调试日志集合。

使用开发人员控制台配置Visualforce页面

现在您已经有了要处理的日志，请开始进行高级分析，以找出请求的哪个部分持续时间最长。

提示:通过按CTRL+P或单击Debug |查看日志面板来设置开发控制台，然后选择以下面板。

 

然后移动窗格(面板边框)，使控制台看起来像下面的布局。这种布局将允许您关注性能分析所需的信息。单击这里快速浏览每个面板。

 

步骤1:阅读请求的时间线。

通过单击执行概述面板中的Timeline选项卡打开时间轴图。此面板将为您提供请求事务的每种类型的持续时间的良好可视化表示。对于这个场景，数据库查询占用了大部分执行时间(2.9秒/ 98.78%)。

根据性能分析的情况，您可能会看到一些不那么明显的东西。例如，更短的Apex事件的突发可能会被重复执行，并且会占用大量的执行时间。下面的示例展示了这样一个请求的外观。虽然“DB”的单个橙色条最初可能表示瓶颈，但该请求仅占总时间的2.5%。您还应该注意表示重复爆发的窄的绿色垂线，它们通常是由无效的顶点循环逻辑引起的。

 

在不同的情况下，您可能还会看到Visualforce页面需要很长时间才能呈现。如果您曾经有过这种类型的事务，请通过参考Visualforce性能:最佳实践来识别编码反模式，它列出了许多客户可能遇到的Visualforce性能缺陷。

步骤2:确定执行的事件正在做什么。

一旦您确定数据库事件占用了大量的总体请求时间，下一步就是确定这个事务正在做什么。打开执行日志面板并选择“Filter”以获取识别瓶颈所需的信息。对于本例，按类别筛选，只显示与“DB”相关的事件，如本屏幕截图所示。

提示:您可以通过悬停在任何现有列上并单击小的下拉图标来定制执行日志面板的列，如下所示。

 

 

因为这个示例非常简单，所以您只能看到一些日志行，其中的顶部显示正在执行的SOQL SELECT语句，最后一个显示结果行数。您现在已经确定了需要检查和调整的SOQL语句

注意:如果您有多个日志行，您可以使用时间戳来标识与您关注的时间轴对齐的行。您还可以按照下一步来评估每个请求的持续时间。

步骤3:检查性能基准。

从堆栈树面板中，单击Performance Tree选项卡并展开树。此选项卡将为您提供相应的持续时间(以毫秒为单位)、堆大小和为您的请求执行的每个组件的迭代。如果你有多个单位，从最长的事件开始，沿着你的列表工作。

 

提示:通过单击似乎会在Performance Tree选项卡上造成瓶颈(最长持续时间)的单元，您可以自动将一个过滤器应用到执行日志，并在时间戳中发现空白。禁用过滤器并查看位于此间隙中的事件。

查看性能树中显示的统计信息，验证它们是否与执行日志中显示的内容匹配。然后注意持续时间、堆大小和迭代次数。使用这些度量作为您在不同条件下运行的测试和调优Visualforce代码后运行的测试的基准。

步骤4:量表测试。

对更大的数据量和不同的用户(例如，数据可见性有限的用户和访问所有数据的管理员)重复相同的步骤。

一旦您开始添加数万条记录，您可能会发现执行时间变得更长。(前面的示例代码最终会遇到调控器限制，比如“System”。通过使用开发人员控制台，您可以检查您离各种Force.com调控器的限制有多近，或者您已经超出了这些限制有多远。下面的示例显示了您可能会收到的一些与限制相关的Visualforce错误。

 

现在您已经发现，需要向应用程序中添加诸如分页或过滤之类的逻辑，以便处理更大的数据集，并最终为用户提供良好的性能体验。

使用Workbench对数据进行概要分析

继续前面的场景，使用Workbench按照以下步骤进一步进行性能分析。对数据集进行概要分析，并评估我们在前一步中发现的潜在的非选择性SOQL语句的选择性。

步骤5:发现SOQL查询性能问题。

使用“已删除和归档的记录:”选项并选择“Include”以获得对象的总体数据量的准确表示。通过使用点单击接口或直接在文本区域中输入语句构建SOQL语句，如下所示。

 

查找大量的软删除行并清除它们，以实现最佳的查询性能。(也可以参考具有大数据量的部署的最佳实践。)

注意:还可以参考存储使用菜单查看对象的记录计数。(从设置中，单击管理用户|用户。)但是，这个页面是异步处理的。如果您添加或删除大量记录，那么更改可能不会立即反映在此页面中。更重要的是，数据不反映软删除的行。当分析性能时，包括基本记录计数中的软删除行数是很重要的，因为这些行会影响查询性能。

步骤6:评估查询的选择性。

要对每个筛选条件的选择性进行概要分析，请分解您的WHERE子句并对每个筛选器运行SELECT count()查询，如上面的图所示。对于和操作符，结合过滤器并评估查询的选择性。对于或操作符，您必须分别评估每个过滤器的选择性。确保您已经索引了选择字段，并且您正在遵循充分利用Force.com查询优化器的最佳实践。如果查询花费很长时间或超时，这表明您有性能瓶颈。要了解更多关于Force.com查询优化器的信息，请阅读本文并观看这个网络研讨会。要了解更多关于其选择性阈值的信息，请参阅数据库查询和搜索优化备忘单。

在Force.com平台上进行概要分析时需要考虑的事项

在分析时，考虑以下内容。

• 调控器限制——在执行日志中使用关键字“LIMIT_USAGE”来检查累积限制使用。确定接近极限的区域。
• 不同的共享设置——通过添加不同角色的用户来迭代性能分析步骤。这种策略可以让您发现数据量和共享计算开销可能带来的性能影响。如果您只使用管理员用户运行测试，那么您可能无法描述这些性能影响——系统不会为已经访问了所有数据的用户执行与共享相关的计算。
• 数据库缓存效果——Force.com平台在后台使用缓存技术来提高查询性能。基于没有缓存影响的请求获得基线基准测试是理想的，但是不能阻止事务使用缓存。在完成第一次概要运行之后，还要进行基于类似条件的其他运行，并比较结果。例如，如果您开始与用户A进行测试，那么运行您的测试几次。最有可能的是，后续的测试会运行得更快，直到某个点。类似地，当您切换到用户B或使用不同的数据集时，遵循相同的策略并运行几次测试。虽然在配置文件运行期间可以看到更好的查询性能，但是不要基于您将始终看到最佳测试结果的假设来设计业务操作和作业。
• 索引的使用——对于查询级别的性能分析，您无法确定您的SOQL请求是否实际使用了索引。但是，您可以通过使用没有任何自定义索引的自定义字段交换查询来测试和查看查询在没有索引的情况下的执行情况。一旦获得查询的基线性能，就可以在该自定义字段上创建索引，或者切换回具有索引的原始字段，以评估索引的效果。
• 负载测试——对于内部实现，负载测试——包括压力、带宽或并发用户测试——通常是性能测试的一部分。在Force.com平台上，负载测试的目标是测试Force.com调控器的限制。这个测试可能会发现一些问题，比如达到顶点并发限制，因为许多用户同时发出请求，运行时间超过5秒。但是，在Force.com平台上不推荐使用具有不现实业务场景的工具来查找服务器容量边界。收集关键信息，如服务器级资源统计信息，以及识别瓶颈是不可能的，而且在大多数情况下，您仅仅是无法获得准确的结果，因为您已经达到了调控器的限制。在运行任何负载测试之前，使用salesforce.com客户支持记录一个案例。

下一个步骤

前面的分析步骤可以帮助您识别和评估应用程序的性能瓶颈。它可能需要多次迭代，您还可能需要额外的帮助来让应用程序执行和扩展，以便满足您的业务需求。

Salesforce.com客户支持和我们的工程团队都配备了工具和标准流程，可以为您的性能分析增加更多的洞察力。例如，如果您发现您没有看到任何应用程序性能改进，即使在您硬删除了您的记录之后，您可能想要请求salesforce.com的客户支持进行物理删除。

您还可以通过salesforce.com客户支持来联系我们的工程团队，他们可以为您提供Force.com查询优化器分析。根据分析结果，团队可能建议使用选择性过滤器并创建自定义索引。团队还可以分析数据库级的统计数据，并可能创建瘦表。

注意:要利用这些服务，您必须获得开发人员支持。

总结

调试日志、开发人员控制台和工作台是您可以用来主动识别性能瓶颈并比较测试结果的工具。理解优化性能的最佳实践是重要的，但是当您试图构建可伸缩的、性能良好的应用程序时——在实现中应用这些最佳实践更重要。

相关资源

• 使用开发人员控制台进行高级测试和调试
• 深入开发人员控制台
• 开发人员控制台
• 工作台
• 视觉效果和顶点的性能调优
• 具有大数据量的部署的最佳实践
• 数据库查询和搜索优化备忘单
• 最大化Force.com SOQL、报告和列表视图的性能。
• 架构师核心资源

Salesforce是SaaS市场上的重量级公司，而Salesforce的问题可能会影响到成千上万的用户。Salesforce有一个在线状态指示板，许多用户利用它来监视应用程序，并确定它是否正常工作并按照预期执行。不过，trust.salesforce.com实际上只是一个Salesforce内部的仪表板，这样你就可以检查Salesforce基础设施和数据中心的所有功能是否正常。它并没有真正显示Salesforce 90%的交付路径上发生了什么。认为它是Salesforce的“检查引擎灯”:它告诉你引擎(应用程序代码)是否运行良好,但它并没有告诉你道路的状况(互联网),是否有道路建设(有限的带宽),或其他车辆占用交通(对资源的竞争)。仅仅因为“引擎”运行良好，并不意味着你能开得很快，很快到达目的地。

Salesforce是一个关键的应用程序，公司依靠它来保持业务向前发展。因此，对于it团队来说，重要的是要意识到并关注可能出现的或已经发生的性能问题，并知道如何在这些问题影响公司运营并最终影响业务之前做出响应和纠正。这里强调的许多问题并不是Salesforce特有的。它们只是在我们的客户群中观察到的成功的SaaS服务示例，而Salesforce提供的插件生态系统要比其他SaaS提供商大得多。

顶级Salesforce问题

以下是我们认为的企业SaaS服务(如Salesforce)的五大性能问题:

1。具体地点的问题。

Salesforce在全球有174个实例(2018年7月更新)，其中56个在北美。与Salesforce实例和所有Salesforce插件的位置相关的办公室位置是理解Salesforce应用程序性能的一个因素。它实际上是Salesforce用户看到的许多性能问题的核心。减少物理距离和网络跳跃到Salesforce的数量会对性能产生巨大的影响。这似乎不是什么大事;没有人会注意到20或30毫秒的延迟。当20或30毫秒被加载到Salesforce web页面上的75个对象上，用户在这个关键任务SaaS应用程序上花费了数小时时，它们就会累积起来。

大多数其他SaaS服务都没有选择您的帐户供应位置的选项。您应该利用Salesforce的这个选项，选择与您的用户地理位置最近的实例，因为这将提供最好的性能。

 

2。低估娱乐流量的影响。

现在，每个员工都随身携带一台或多台能够传输高清视频和音频的设备，其中大部分设备将自动连接到公司的无线网络。随着人们带着移动设备工作，并使用本地无线网络流媒体，你可以发现你的带宽容量正在紧张或被消耗，导致诸如Salesforce这样的关键应用程序急需资源。我们遵循了我们自己的最佳实践，为个人设备建立了一个单独的无线网络，因此Salesforce拥有大量可用的带宽。缓解移动设备问题的一种方法是为你的员工正在使用的所有平板电脑、智能手机和其他移动设备建立一个独立的客户无线网络，并防止他们通过使用MAC地址过滤进入常规的内部网络。这样，您就可以分别为每个网络提供带宽，允许您控制不同设备的可用容量。

 

3. .低质量的带宽。

当web或SaaS应用程序(如Salesforce)运行缓慢时，许多公司认为它们应该投资于更多的带宽。这是一个真正的问题，但在升级office带宽之前，应该先看看这是否真正阻碍了他们的Salesforce性能。例如，在我们波士顿的办公室里，我们得到的带宽是250mbps，而Salesforce实例的带宽连接非常高，但是我们与Salesforce的连接速度是5mbps。

对于大多数我们工作的公司来说，获得更多的带宽并不能使Salesforce更快或更好地发挥作用。让它表现得更好的是获得更高质量的带宽。Web应用程序是基于tcp的，具有保证的交付，并且少量的数据包丢失将对Web应用程序的性能产生不可思议的影响。当一个web应用程序有3%到5%的包丢失(也由基于流的应用程序的重传速率表示)时，该应用程序的总体用户体验将是糟糕的。解决方案是确保您没有遇到包丢失和在当前的Internet连接上重新传输，并确保您和ISP的网络设备正常工作。许多公司从住宅级升级到商务级或其他专用电路的原因是为了确保更严格的公差、更好的设备以及减少web应用程序丢失数据包的机会。

 

4.智能缓存。

像Salesforce这样的Web应用程序有大量的JavaScript和CSS文件，以便提供丰富的用户体验，这种体验可以与人们在桌面应用程序中体验到的体验相媲美。因此，您将有3、4或5 MB的JavaScript文件需要时间下载，特别是当您有包丢失时。这一特定页面有多个插件使用我们的销售团队总页面大小5 MB。因为它很少改变,如果你可以在你的网络启用高速缓存,并创建一个缓存的导数它存储在本地,你会支持大文件下载和为用户创造一个更好的体验当加载Salesforce。

5。插件使用。

普通的Salesforce客户在Salesforce有7个插件，每个插件都可以极大地帮助或损害Salesforce的最终用户体验。您的大部分数据传输实际上可能来自这些第三方插件，它们与Salesforce合作，提供领先的来源、营销、销售和会计功能。因此，您想要探索您的插件使用了多少带宽，以及这些插件在哪里使用。在选择可用的插件时，应该考虑这些插件的性能影响，而不仅仅是它们的特性。要评估这些插件的全部性能影响，您需要一个工具，该工具使用一个真正的合成事务来度量最终用户的完整体验，因为这将使您能够看到，不仅Salesforce在正常工作，而且您的插件也在正常工作。

 

这些是您和您的IT团队可以监视的基本领域，以定位、避免和解决Salesforce性能问题。即使您在如何运行Salesforce方面做得很好，您也需要确保整个底层基础架构能够交付高质量的Salesforce体验。在AppNeta，我们花了大量的时间来确保我们的工具能够监控像Salesforce这样的SaaS应用程序，在它们影响用户体验之前及时发现这些问题。

 

2014年7月更新

对于在Salesforce平台上实现应用程序的架构师或开发人员来说，在分析应用程序性能时，网络性能测试变得越来越重要。本指南涵盖了帮助您识别风险并找到网络相关挑战的解决方案的最佳实践。

介绍

分析应用程序性能和运行性能测试是关键的“实验室”活动，以验证您的Apex和SOQL代码是为可扩展性而优化的，Visualforce页面设计是遵循最佳实践的。但是，为了确保您的应用程序已经为现实世界做好准备，您还需要考虑到用户将从具有不同级别网络连接的不同地理位置访问它。作为架构师，您的任务是成功地启动一个应用程序，即使使用这种网络变体，该应用程序也能运行良好。您肯定不希望在产品上线后听到终端用户说“为什么我的页面加载时间这么长，而我的同事可以在一秒钟内加载它?”继续阅读，学习最佳实践，帮助您识别风险，并作为架构师找到解决网络相关挑战的方法。

评估Salesforce用户的网络性能

如果有人问“为什么我的页面加载时间这么长，而我的同事可以在一秒钟内加载它?”“用户的设置可能不同，呈现内容的时间和大小也不一样。”为了确保你在将苹果和苹果进行比较，并将重点放在网络上，你必须有一个理想的受控设置:

在两个或多个不同的位置至少有两个几乎相同的终端(PCs)。在地理上更接近Salesforce数据中心(即:，以及其他远程站点(例如。)。

使用相同的浏览器和用户(或用户集)访问目标(例如，Visualforce页面)，以排除尽可能多的变量。

使用相同的工具来度量时间(以下部分将对此进行解释)。

在类似的时间范围内运行测试，以评估与网络带宽相关的问题，并多次排除缓存影响。

如果您无法访问远程位置来运行测试，那么可以使用Charles或Shunra之类的工具以及netem和ipfw之类的实用工具来人为地添加延迟和带宽限制，以模拟不同的网络环境。

一旦有了受控的测试设置，您就可以收集基准统计数据并使用它们来迭代地评估性能调优工作。不管你如何设置你的测试，或者你选择使用什么工具来运行它们，我们最终追求的是两件事:

• 减少负载。
• 减少网络延迟。

为了简单起见，我们将在下面几节中逐一讨论。但是，请记住，这两者都要看，而不仅仅是一个。

减少负载

减少有效载荷的目标是减少网络时间。由于您正在测试和比较内容大小一致的相同页面，因此在服务器端和在客户端呈现的时间应该非常相似。下载资源所花费的时间差异越大，与请求的总持续时间相比，它所占的比例越大，通过检查页面设计和减少负载，您可能会得到更多的网络性能改进。

您不需要使用花哨的应用程序性能监视(APM)工具来评估负载。您可以使用免费的浏览器工具来收集关键指标。Chrome、Firefox和Internet Explorer都有类似的工具，它们可以为您提供从页面请求发送到Salesforce到用户感知到页面被“加载”到整个呈现过程完成的时间的图形表示。您还可以使用Fiddler或Charles等工具进行高级分析。

当这样做时，不要太过迷于字节大小，工具会显示每个被下载的资源。交换数据不会按位(或按字节交换数据)进行。它们以分组的形式通过电线传送。例如，如果您处理了几个映像文件以减少这里和那里的一些字节，但是没有看到性能有多大的提高，很可能是因为您没有减少每个资源下载的数据包的实际数量。如果你有一个高度图形化,动态页面有很多资源,比如图像、CSS或者JS文件,结合他们或拼接,然后削减他们可能会有更大的效果比减少一小部分的大小和仍然需要十(希望不是数百)资源并行下载。您还可以使用其他通用的web应用程序优化技术来最小化下载负载、减少往返行程和握手等。

更重要的是，确保检查Visualforce性能最佳实践，并在Salesforce1平台上构建高效的Visualforce页面。例如，删除不必要的Visualforce标记，这会增加页面视图状态的大小。通过仔细选择用户所需的字段和使用诸如分页之类的技术，限制在页面上加载和显示的数据量。如果您有一个多步骤的向导应用程序，该应用程序将引导用户遍历一个流程，请考虑实现一个解决方案，使页面之间的转换成为无状态。如果您有一个允许用户使用大量字段更新记录的表单，那么只发送delta信息，而不发送整个数据集。

减少网络延迟

当您通过优化应用程序来减少目标页面的有效负载时，您还应该在得出结论之前查看网络层，您无法使最终用户更接近Salesforce服务器。

您可以使用诸如Traceroute (Traceroute)或更高级的工具来进行更深入的分析。在salesforce，我们有几个第三方工具可以持续地监视和收集各种网络相关的度量，我们还可以根据需要部署这些工具，以便从远程站点解决问题(请联系客户支持以获得帮助)。这些工具可以让我们很好地了解RTT、BGP路由以及帮助发现问题区域的包丢失率等细节。下面几节将解释如何使用这些度量来确定如何减少网络时间。您最有可能参与您的IT、网络工程或ISP团队，以获取统计数据并进行深入分析。

减少延迟

使用Salesforce时，大多数浏览器页面或移动应用程序请求都是突发的事务，每个请求都需要多次往返Salesforce服务器，以建立连接、发送/接收数据，并确认交换的每个数据包。

从网络的角度来看，你应该注意两个关键方面:

• 实例不是分布在多个数据中心(除了在地理远程数据中心待命的灾难恢复克隆之外)。换句话说，在任何特定的时刻，用户事务都是连接到我们的数据中心的。
• Salesforce.com采用与运营商无关的体系结构，它通过连接到多个行业领先的网络供应商，这些供应商直接位于每个数据中心边界的边缘，拥有高带宽的骨干。这提供了冗余和灵活性，以便为通过Internet连接的用户提供最佳的网络性能。

虽然由于用户和Salesforce之间的地理距离而增加的延迟是固定的，但是可能有机会减少特定于用户网络的“拓扑”延迟。确保你至少涵盖以下内容:

• 优化BGP - BGP路由在确定数据包通过internet发送时的延迟方面起着重要作用。在极端的情况下，您的数据包可以通过更长的方式在全球发送到Salesforce，也可以跳过过多的中继点，每次都增加了延迟。虽然优化BGP有时更像是一门艺术，而非科学，但我们在仔细研究和改变网络路由偏好之后，看到了巨大的收获。使用网络监视和分析工具，比如千分之一和Appneta提供了发现问题的洞察力。
• 避免不稳定路径——最短路径不一定是最好的路径。考虑由于网络稳定性问题的影响，如数据包丢失和数据抖动。如果任何一端在给定的时间范围内都没有收到预期的包(例如，放弃等待另一端的确认)，那么它将重新提交最后一个包，然后等待多次，每次都乘以并增加总体延迟。由于RTOs和SRTTs的增加，地理延迟的影响变得更糟。与BGP分析类似，监视工具可以识别具有稳定性问题的路径。基于调查，您可以与您的网络团队和isp一起优化路由，以修复或避免已知的具有稳定性问题的路径。这将导致数据包重新传输的减少，这意味着在冗余的数据包交换上浪费的时间更少。
• 识别瓶颈——您的网络中可能存在一个正在增加延迟的中间设备。通过使用Wireshark之类的工具，并与您的IT/网络团队和Salesforce支持紧密合作，包级跟踪分析可能会发现与次优或在您的办公室或托管数据中心中配置不当的设备相关的优化机会。您可能还会发现，除了salesforce提供的资源之外，对其他资源的访问也显示出性能问题。
• 避免重定向——每个重定向添加到整个RTT中，并导致许多往返重定向服务器的往返，以完成SSL握手。评估并避免不必要的重定向。例如，启用My Domain并将登录请求指向My Domain URL，而不是常规登录页面。如果已经实现了SSO，请确保将SAML断言发送回My Domain端点。请参阅本指南，了解可以应用于减少由于重定向造成的延迟的其他技术。

利用CDN

如果您有一个构建在Force.com站点上的公共页面，并且没有通过SSL提供服务，salesforce提供了一个缓存选项，允许您利用我们合作伙伴的内容交付网络(CDN)。CDN通过从地理位置更靠近用户的缓存服务器上提供静态资源来提高页面加载时间。这种方法对减少网络延迟也有类似的效果。

带宽利用率最大化

如果您知道您有一个本地分支办公室，它的吞吐量有限，许多用户共享这条线，那么这可能是需要研究的内容。然而，让1Gbps企业骨干离开您的办公室并不意味着您不必担心带宽，因为带宽利用率受到延迟和TCP窗口大小的限制。对于涉及到的所有各方来说，控制TCP窗口大小配置可能并不容易，但是对于存在问题的客户机PC来说，这是一个值得研究的调优机会。有关细节，请阅读下面的内容。要了解更多关于使用salesforce的带宽需求，请阅读本文的帮助文章。

集成设计注意事项

如果您将Salesforce之外的服务集成为应用程序设计的一部分，请考虑以下内容:

• 可以使用mashup (i-frame)技术直接与客户端进行调用，而不是通过salesforce平台进行多次往返。这种方法对减少网络延迟也有类似的效果。
• 握手和数据传输最小化(通过批处理和压缩)以减少有效负载也很重要。应该仔细调整超时设置，以平衡延迟，避免占用连接太长时间。对于API调用，并行化(如果可能的话)可以帮助减轻延迟的一些负面影响。
• 幂等性也是一个关键的设计考虑因素，尤其是在网络连接不佳的情况下。您应该假设在完成之前任何事务都可能失败，并且所有来自远程服务器/服务的请求都应该工作，并且只工作一次，以允许多个重试，而不会带来数据完整性问题。

总结

确保您的页面加载时间目标不仅在您的开发实验室设置中得到满足，而且对于具有额外延迟或次优网络连接的远程用户也是如此。研究web页面优化技术以及消除网络瓶颈以减少网络时间。这将确保您不会听到终端用户“为什么我的页面加载时间这么长?”

Knowledge :000250291

描述

如果您或您的用户在使用闪电体验时正在经历缓慢的页面加载时间，它可能与以下一种或多种问题类型有关。

• 地理
• 设备
• 浏览器
• Salesforce组织配置问题

请审阅以下的问题描述和缓解策略，以提高您的销售团队为闪电用户的性能。

解决办法

地理问题

从不同的地理位置访问主机实例(例如，一个组织在北美托管，但用户从亚洲访问它)。

由于客户端设备和远程web服务器之间的延迟问题;或客户网络拓扑，如虚拟专用网络，在Salesforce环境中重新路由到客户的org之前，需要通过公司办公室或数据中心路由通信。

潜在的缓解措施

评估网络延迟:请公司的网络管理员或IT专业人员在连接到Salesforce环境时评估网络延迟。它们可以运行“ping”或“traceroute”等实用程序来收集数据，然后确定优化网络连接速度的方法。您还可以在这里测量下载和上传速度到您的Salesforce实例:https://[instance .salesforce.com/speedtest.jsp。

设备和Browser-Related问题

使用笔记本、台式机或虚拟桌面基础设施，没有足够的处理能力或内存。或者有多个应用程序在争夺设备的资源，比如CPU和内存。

使用带有消耗大量CPU或内存的插件或扩展的web浏览器。

同时运行太多的浏览器选项卡。每个选项卡消耗内存和CPU周期。

潜在的缓解措施

评估浏览器处理能力:

使用Octane来度量浏览器对客户端设备(笔记本、桌面、工作站或虚拟桌面)的处理能力:https://chromium.github.io/octane/。如果辛烷值小于15000，闪电体验性能可能会比较慢。高端客户端设备的辛烷值通常大于3.2万。辛烷值越高，闪电体验性能越好。你可以尝试以下步骤来提高客户的Octane 值:

• 确保笔记本电脑完全充电或连接电源。当笔记本电脑用低电量运行时，它会以较低的速度运行以节省电力。
• 如果可能，关闭在客户端设备上运行的其他应用程序。
• 如果可能，将浏览器设置重置为原始默认设置。
• 删除未使用或不必要的浏览器插件和扩展。
• 将客户端设备升级到具有更多处理能力和内存的模型。

禁用不必要的插件和扩展:

浏览器插件和扩展对闪电体验性能的影响取决于它们消耗多少CPU能量或内存资源。禁用特定的插件或扩展，以查看更改是否会导致更高的辛烷值。对于每个浏览器来说，禁用插件的方法是不同的。例如，在Chrome中，通过输入:Chrome://plugins/或Chrome://extensions/。

使用最新的浏览器版本或补丁:

浏览器供应商通常会发布更新的版本或补丁，并进行修复，以提高性能、安全性或稳定性。

切换浏览器:

性能因浏览器而异。Chrome一直是最快的闪电体验浏览器，而ie浏览器通常是最慢的。

重新启动浏览器或设备:

每周重新启动浏览器和客户端设备一次可能会有所帮助。运行各种应用程序的客户端设备或浏览器可能比需要的时间更长。释放这些资源使浏览器和操作系统的资源管理更加高效，允许浏览器和操作系统在经常使用的应用程序(如Lightning Experience)上花费更多的时间和系统资源。

Salesforce组织配置

• 使用未经优化的Visualforce实现。
• 激活Aura调试模式。
• 使用具有复杂结构、大量组件或数百个字段的闪电页面。这些类型的页面需要更多的时间来处理和呈现。

潜在的缓解措施

优化您的Visualforce页面:

遵循我们在优化Visualforce性能开发人员文档的最佳实践中提供的指导方针。

禁用Aura调试模式:

您的组织可能已经启用了Aura调试模式，以便更容易地在Lightning组件中调试JavaScript代码。但是运行Aura调试模式会降低闪电体验的性能。要在sandbox和production orgs中关闭此模式，请转到Setup，选择Lightning组件，然后取消选择Enable Debug模式复选框。

重新配置处理密集型页面:

如果您的Salesforce org有大量字段、低效的自定义组件或复杂的页面配置的页面，请考虑降低它们的复杂性，以提高呈现加载时间。

1. 流线化最初仅对与用户功能相关的字段可见的字段的数量。您可以使用配置文件来实现这一点。
2. 将页面上的元素(包括字段、相关列表和自定义组件)分解为选项卡。在第一个选项卡上显示最需要的信息，并将辅助信息移动到后面的选项卡上。将不太重要的组件移动到一个或多个Lightning页面选项卡之后。不在主选项卡中的组件不会在初始页面加载中呈现，而是只按需呈现。例如，将新闻和Twitter组件移动到次要的“新闻”选项卡。
3. 所示。细节:将细节组件放置在辅助选项卡中，或者减少显示在细节面板中的字段。这将对组件的呈现时间产生线性影响。
4. 所示。相关列表:将相关列表组件放在辅助选项卡中，可以使用新的“相关列表”组件在主页面上显示一个或两个关键的相关列表。将相关列表的数量减少到3个或更少。
5. 自定义组件:通过使用或不使用组件进行测试来量化自定义组件的影响。有些组件可以重构为闪电动作或应用通用优化。

Lightning组件执行最佳实践

为了了解更多关于闪电经验的有用的最佳实践，请回顾我们的Lightning Experience(闪电组件)性能最佳实践。