在本指南中，您可以了解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、报告和列表视图的性能。
- 架构师核心资源