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页面优化技术以及消除网络瓶颈以减少网络时间。这将确保您不会听到终端用户“为什么我的页面加载时间这么长?”
Tags
最新内容
- 6 minutes 31 seconds ago
- 14 minutes 2 seconds ago
- 24 minutes 46 seconds ago
- 4 hours 45 minutes ago
- 6 hours ago
- 6 hours ago
- 6 hours ago
- 1 week 1 day ago
- 1 week 1 day ago
- 1 week 1 day ago