2016年3月31日,星期四

Office 365性能–我们的Azure CDN映像再现解决方案

在上一篇文章中 图像复制导致SharePoint Online中的页面加载缓慢,至少在目前,我谈到了Office 365 / SharePoint Online如何在图像和图像再现方面具有次佳的性能。许多人联系说他们也看到同样的问题。但是,我们是实施者-我们带来解决方案,而不是问题!所以在这篇文章中’我们将更详细地介绍如何解决此挑战,以及如何改善页面加载时间。

概括地说,该问题与SharePoint的图像再现功能有关。这是一项有用的功能,它可以在发布站点(例如Intranet)中自动创建图像的其他版本(大小)。但是,当用户点击包含这些图片的页面时-通常是首页或版块页面–并且需要下载它们,我们会看到最多3秒钟的延迟。显然,如果一个页面总共花了5到7秒钟来下载,那么这段时间是很大的一部分。令人惊讶的是,延迟不是通过导线发送给用户的实际图像。相反,分析显示在SharePoint Online中的服务器上发生了3秒左右的暂停–最可能是因为“cache misses”由于存在引渡框架’最初是为Office 365中使用的体系结构设计的。因此,该平台的性能不佳。’最佳-我们的解决方案是推出自己的演绎框架,而这篇文章介绍了我们所做的事情。

使用Azure实施演绎

在深入研究实现之前,这里’上周我对流程的描述:

  1. Intranet作者在SharePoint中添加或更改图像
  2. 远程事件接收器执行,并将项目添加到Azure中的队列 (注意–RER并非具有故障安全性,因此我们通过一种后备机制来补充此方法,以确保不会发生损坏的图像。详情请见下文。
  3. Azure WebJob处理队列项目,采取以下步骤:
    1. 从SharePoint获取图像(使用CSOM)
    2. 创建不同的再现大小(使用SharePoint中定义的大小)
    3. 将所有结果文件存储在Azure BLOB存储中
  4. 然后,Azure CDN基础结构将映像文件传播到世界各地的不同Azure数据中心。
  5. 在SharePoint中显示图像时,将使用指向Azure CDN的链接(由对显示模板代码的细微调整提供)。由于CDN通过提供一个URL来工作,因此路由会自动进行,因此将获取与用户最近的图像副本。

对于那些感兴趣的人,让’进入主要元素:

远程事件接收器和关联的SharePoint应用程序/加载项

这里有两个元素:

  • 用于我们的远程代码(托管在Azure中)的SharePoint加载项,以验证回SharePoint
    • 我们使用AppRegNew.aspx注册此加载项,并指定将用于SharePoint身份验证的客户端ID和客户端密钥。
  • 远程事件接收器,用于检测何时添加新图像

这两个是相关的,因为我们使用Visual Studio模板将RER代码实现为提供程序托管的加载项(提供2个项目,一个用于应用程序包,一个用于应用程序网络)。实际上,该特定RER并没有’不需要与SharePoint通信–当它触发时,它只是将一个项目添加到我们提前创建的Azure队列中。添加到队列中的对象包含刚刚添加或修改的图像的URL,我们使用Azure SDK进行调用。

我们将此RER应用于站点中需要解决方案的所有图像库。我们仅通过一次性遍历所有子站点的PowerShell / CSOM脚本将其作为一次性设置任务来完成,对于每个图像库,它都会发现它绑定了RER。我的帖子 在Office 365中的PowerShell脚本中使用CSOM 显示了一些类似的代码片段,我们对此进行了扩展。如果需要,可以按计划运行脚本,这样任何新的图像库都会自动运行“inherit” the event receiver.

Azure WebJob

主要工作在这里完成。该作业被实现为“continuous”在Azure中工作,我们使用 Azure队列触发器 轮询队列中是否有新项目。这是Azure中的基础结构,这意味着只要将新项目添加到队列中,我们的WebJob代码中的功能就会被执行– it’有效地是一个监视器。我们最初考虑使用BlobTrigger代替(并让RER本身将映像上传到Azure BLOB存储以方便此操作),但是我们没有’不喜欢BlobTrigger在处理中可能会有更大的延迟这一事实–我们希望事情尽快完成。此外,远程事件接收器在进行最少的处理工作时效果最佳–而且由于快速异步REST调用比复制文件字节轻得多,因此我们更喜欢这种模式。检测到新项目时,核心步骤为:

  1. Fetch details of the 默认 rendition sizes defined in SharePoint for this site. This tends to not change too much, so we do some caching here.
  2. 使用对SharePoint的REST调用获取此图像的* specific *再现大小的详细信息。我们需要执行此操作以支持出色的演绎功能,该功能允许作者针对特定演绎内容专门放大/裁剪图像的一部分。– y’know, this thing:

    图像再现-裁剪图像

    If an author uses this feature to override the 默认 cropping for a rendition, these co-ordinates get stored in the *file-level* property bag for the item, so that’是我们从中获取它们的地方。
  3. 从SharePoint图像库中获取实际图像。我们使用CSOM和SharePoint加载项身份验证进行此调用–我们的WebJob知道要使用的客户端ID和客户端密码。我们获取文件字节,即有效地将文件从Office 365下载到运行我们代码的位置(Azure),因为我们当然’将需要该文件才能创建其不同版本。
  4. 对于每个所需的再现大小:
    1. 将图像调整为这些尺寸,并遵守我们发现的任何X和Y起始坐标(如果作者确实覆盖了该图像的裁剪)。有很多方法可以处理图像大小调整,但是在评估了几个之后,我们选择使用流行的 图像处理器 库来做到这一点。
    2. 将每个文件上传到Azure BLOB存储。我们使用Azure SDK中的方法上载,并确保文件具有根据我们使用的URL约定的文件名–这很重要,因为我们的显示模板需要与此保持一致。

将文件上传到Azure BLOB存储后,’实际上是我们需要担心的。如果您使用Azure CDN,则自动使用存储在其中的文件’已经以某种方式配置了Azure CDN。一世’稍后将对此进行简要介绍。

Azure WebJob的身份验证

我认真思考了一下身份验证。最后,我们采用了SharePoint仅应用程序身份验证,但是我们还考虑了对远程代码使用Office 365 / Azure AD身份验证。坦白说’s my “default”这些天来,任何与SharePoint通讯的远程代码(假设我们’重新谈论Office 365)–正如将Office 365应用程序与SharePoint加载项进行比较中所讨论的,在大多数情况下,它具有许多优点,其中包括没有“installation”插件,身份验证流可以在SharePoint外部启动。

但是,使用SharePoint身份验证的优点之一是 我们不是’与使用与Office 365租户背后相同的Azure订阅/目录相关联。我们的客户可能并不总是能够提供支持,在这种情况下,这对我们很重要–使用这种方法意味着我们不’没有那种依赖性。

显示模板

如前所述,解决方案的很大一部分是确保SharePoint显示模板与CDN中的文件URL对齐。所以如果我们’重新使用汇总控件(例如网站周围的Content Search Web部件)以及这些参考格式图片,这些还需要“know the arrangement”. Effectively it’这是一个确保将文件放置在其中的事物和请求文件的事物都在交易中的问题(就了解URL的命名约定而言)。它’在这里,我们还实现了回退机制(稍后会对此进行详细介绍)来处理请求的图像不存在的任何情况。’t在CDN上找到。在将默认情况下,即从SharePoint获取图像的默认行为换成从CDN获取图像的行为,这取决于如何在SharePoint中使用值<img src>获得属性:

<img src="_#= imgSrc =#_" />

只需实现一个函数即可根据您的URL约定获取该值,然后您’好。尽管未在上面的代码段中显示,’在这里,我们的后备机制被称为‘onerror’ handler on the <img> tag.

WebAPI

因为我们’在谈论建筑作品’还有一些WebAPI– this is part of 后备机制, described later.

Azure CDN配置

如前所述,使用Azure可以轻松实现CDN部分。当文件上传到Azure BLOB存储时,它将获得以下形式的URL:

http:// _ [MyAzureContainer] .blob.core.windows.net / MyImage.jpg

..但是如果您配置CDN,也可以通过以下方式访问它:

http:// _ [MyCDNEndPoint] .azureedge.net / MyImage.jpg 

使用后一个URL时,实际上将从最近的Azure CDN数据中心向用户请求文件。如果文件没有’如果尚未传播到该位置,则要路由到该位置的第一个用户将强制将文件缓存在那里,供该地理区域中的其他用户使用。我们的测试发现,这种额外的延迟很小。 CDN需要考虑的事情比我还多’我会在这里详细介绍,但是初始配置很容易–只需在Azure中创建一个CDN配置,然后指定它由Azure存储支持,然后选择您要在其中使用的容器’重新放置您的文件。下图显示了此过程:

 图片

从BLOB存储创建CDN端点

后备机制

所以我提到了几次我们所说的“后备机制”。我一直很担心我们的解决方案有时会导致图像损坏 –我只是可以想象,这将是关于CEO的一些重要新闻文章,对于我们的一位客户而言,是重要的一天。幸运的是,我们能够实施似乎很好的保护层。简而言之,我们“intercept”使用HTML 5损坏的图像‘onError’ callback for the <img>标签。如果图像不存在则触发’出于任何原因而在CDN上被发现,这启动了我们的机制,该机制有两个作用:

  1. 替换SharePoint中的原始演绎图像 -这意味着我们’re “回到原来的情况”, and we haven’没有使任何事情变得更糟。
  2. 对我们的WebAPI服务进行后台异步调用 –这会将一个项目添加到Azure中的队列中,这意味着图像将在下次处理。这与RER针对此特定文件触发的情况相同。

下图显示了发生的情况(单击放大):

CDN映像再现-后备机制2

关于此机制的一件好事是它适用于站点中的现有图像。因此,如果该机制是在具有大量图像的现有站点中实现的,’不用转转“touching”每个图像触发远程事件接收器。取而代之的是,所有需要发生的事情就是让某人在站点周围浏览,并且图像将根据请求迁移到CDN。

我们遇到的挑战

一路上,我们面临着一些挑战,或者至少要考虑一些事情。这里的快速列表包括:

  • 考虑来自Azure CDN的缓存标头,缓存过期等–这与作者可以在SharePoint中更新图像而不更改文件名的方案有关。显然,最终用户浏览器可以缓存该图像(最终用户可以’不能仅仅因为您就按CTRL F5进行硬刷新’ve更新了文件!)。我的同事 保罗·瑞安 为此写了一篇很棒的文章 Azure CDN与SharePoint集成,缓存控制标头max-age,s-maxage
  • 并行上传到Azure(例如’重新为找到的图片创建8种不同的尺寸,也可以并行上传!)
  • 确保我们了解如何处理不同的环境(具有不同Azure订阅的开发/测试/生产租户)
  • 实施一个不错的日志记录解决方案
  • 测验

概要

正如我上次总结的,如果Office 365中的原始性能问题没有’不会发生。但是CDN一直在优化网站性能方面一直很有用,在许多方面我们’这样做是在扩大微软’Office 365背后CDN的现有使用。AzureWebJobs,Azure文件存储,CDN,SharePoint加载项,远程事件接收器,WebAPI等构建模块意味着Office 365 / SharePoint Online平台可以进行各种扩展适当的方式。这是为以下客户开发的解决方案 内容和代码 所以’我无法提供源代码,但是希望这两对文章有助于您了解问题的一种解决方法以及体系结构的详细信息。

2条评论:

克里斯蒂安·M说过...

克里斯,这看起来很棒!

您是否有机会在GitHub页面上共享其中的一部分?我很想看看"共享点有一个螺栓" so to speak :)

克里斯·奥'Brien说过...

@克里斯蒂安,

谢谢:)但是我'm afraid I can't share the code, it'属于公司I的有效IP'm使用(内容和代码)。

如果您决定创建类似的东西,那么祝您好运!

干杯,

COB。