2016年3月22日,星期二

Office 365性能– image 演绎s causing slow page loads in SharePoint Online

就像任何网站一样,在SharePoint Online中页面加载时间可能并不惊人的原因有很多。也许吧’一页太多‘heavy’控件(例如搜索Web部件),特别慢的自定义控件,在线传输的数据量(例如由于大双色球推荐一注的JavaScript / CSS文件),使用已知的性能杀手(例如结构导航),或者速度很慢由于诸如反向代理之类的网络基础架构而使办公室运行缓慢,因此可以从办公室中删除。如果用户远离Office 365租户所在的位置,那肯定会加剧情况。与往常一样,如果网站具有任何类型的自定义,则需要采取一些优化步骤-可以获得良好的性能’总是默认情况下发生。但是最近,我们’我们注意到,即使在以下情况下,页面加载速度仍然很慢

  • 我们优化的网站
  • 开箱即用的发布网站

Analysis showed that the issue was related to image 演绎s in SharePoint. If you’对此功能不熟悉,它做了一些有用的事情,具有讽刺意味的是,它旨在提高网站性能。对于每个上传的双色球推荐一注,多个 调整大小 版本会在后台自动创建–这个想法是最终用户不要’t download a large ‘original’仅需要很小的缩略图时的双色球推荐一注。经典示例是将大双色球推荐一注添加到内容页面,然后将其显示为主页上的上卷链接列表,例如“最新新闻文章”.

如果不是’对于性能问题,原理很好–对于一个典型的大小,一个4MB的双色球推荐一注通常会缩小到200k左右,并且’s a 很多 更少的数据下载给用户。一世’我不确定最近在Office 365中是否进行了任何更改(因为大多数网站’ve been involved in use image 演绎s), but a couple of clients 不iced the issue around the same time we did. Specifically, pages with 演绎s are slow on “first-time” page loads 也就是说,由于本地浏览器缓存中没有提供图片而需要下载图片时。但不幸的是’s 不 just that - 演绎 image files are served with expiry headers of 24 hours, meaning 即使是普通用户,每24小时也会有至少一个非常慢的页面加载。当然,我们可能不仅在谈论他们的主页– rather, 每一个 每24小时一次,他们点击的网页可能会变慢。那’肯定足以破坏用户对Office 365的认识。

边注– 第一次 page loads vs. returning user page loads
因此,即使在首次加载页面时,翻译也很慢。但是当我们’关于这个主题,我们无论如何需要关心首次页面加载?我通常建议我的客户不要太担心–坦率地说,Office 365在这里总是很慢,因为需要下载一些非常繁琐的JavaScript文件(即使它们确实来自CDN)。它’毕竟是一个功能丰富的平台。但这是Office 365设计的很大一部分–我相信Microsoft认为用户会宽恕,只要他们的*“后续”浏览体验很快即可。大多数用户不’对企业内部网/协作平台的期望与对公众消费网站(如Facebook和Google)的期望相同–而且由于大多数Intranet的使用都是*不是*首次页面加载,因此最终效果良好。我坦率地同意这一观点。

But why are image 演绎s slow?

当执行进一步分析时,我们看到延迟发生在服务器上–最大的惊喜是延迟是 要下载的实际双色球推荐一注,这就是您’d通常期望。下图显示了一个正在加载的真实主页,我们可以看到许多双色球推荐一注都有几秒钟的延迟(每个双色球推荐一注都是一个“rendition”图片),如绿色长条所示:

渲染双色球推荐一注延迟_小

当我们深入研究时,我们看到延迟不是在内容下载中,而是在“waiting” stage –这表明延迟与Office 365本身有关,并且 在实际下载的文件中:

渲染双色球推荐一注延迟-detail_Small

我们认为,发生这种情况是因为通常“cache misses”从BLOB缓存提供的演绎双色球推荐一注上。当不从Blob缓存中提供双色球推荐一注时,SharePoint Online基础结构处理和提供双色球推荐一注的速度非常慢。看来快取 命中 对于最终用户来说非常罕见–可能部分是由于SPO中的BLOB缓存设置(例如,允许的磁盘大小),但更有可能是由于典型SPO服务器场中的前端服务器数量过多。一世’m告诉我们,该服务中的一些较大的服务器场现在具有100到200个前端服务器–显然,这与SharePoint最初设计用于的本地环境完全不同。因此,尽管演绎体系结构在一个典型的本地部署服务器场(例如3-6个前端Web服务器)中将非常有效,但在Office 365世界中并非如此。当然,如果您与产品紧密合作,有时会看到一些类似的事例,’完全可以完美地转换为云世界。话虽这么说,但我曾参与过许多部署’我总是对SharePoint作为一项服务的工作表现感到惊讶(毫无疑问,这是由于有才华的Microsoft工程师(包括我认识的一些人)的辛勤工作)-但总会有“改善的机会”,并且服务通常会演变为包括这些内容。

我们的解决方案(基于Azure CDN)

那么我们能做些什么呢?好吧,我们可以避免完全使用SharePoint双色球推荐一注副本,但是由于将大文件下载给用户,因此性能仍然很差。所以我们一定要使用不同的双色球推荐一注尺寸–由于调整双色球推荐一注大小的核心工作是’这么辛苦,为什么不自己做呢?然后,我们可以利用其他优势,例如自动使用CDN,例如 Azure CDN (注:该链接说明了CDN在您进行’不熟悉)。这是我们解决SharePoint Online性能问题的方向。事情进展顺利,我们实现的好处如下:

  • The Office 365 演绎s delay does 不 occur
  • 对Intranet最终用户没有影响(改进的性能除外)
  • 内联网作者不需要做任何其他事情或接受其他培训
  • 双色球推荐一注文件托管在Azure CDN(内容交付网络)中,该文件将文件放置在世界各地的各个Azure数据中心中,以确保它们与用户接近。对于某些用户,尤其是远离Office 365数据中心的用户(例如,对于大多数客户而言,非欧洲用户),这可以显着提高性能。
  • All of the capabilities of the image 演绎s framework are supported (e.g. the ability for an author/administrator to crop an image 演绎 so that a certain 一部分 图片的使用)

技术一我们的解决方案架构

I’在下一篇文章中将进行更详细的介绍,但简要地讲,我们的解决方案如下:

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

如下所示:

CDN image 演绎s for SPO

后备机制

显然’对于Intranet主页从不显示损坏或丢失的双色球推荐一注至关重要–对于大多数组织而言,这将是一件非常糟糕的事情。那么我们如何防范呢?另外,我们说远程事件接收器不能100%可靠(也不应这样做)“heavy”处理工作),所以…..那个怎么样?在实施此类解决方案之前正在运行的站点中的现有映像又如何呢?我的同事 保罗·瑞安 当我设计解决方案并编写代码时,我努力应对了这些挑战以及更多挑战-我’我将在下一篇文章中更多地讨论后备机制(涉及这些方面),并在技术实现上进行更详细的介绍。 

概要

如果这个问题没有发生,那就太好了’当然,它首先存在于Office 365中。但是我写这篇文章是为了表明,有了正确的构建块,我们当然可以付出一些努力来补充Office 365 / SharePoint的功能。这是为以下客户开发的解决方案 内容和代码 所以’我无法提供源代码,但是希望本文可以帮助您了解该问题以及解决该问题的潜在方法。下次更多

8条评论:

戴夫说过...

I'd我本人也注意到了同一件事-最近也是如此。直到几个月前,翻译工作仍按预期进行,现在可能需要几秒钟的时间才能出现。

我想知道是否在那里'这是一个回归问题,而不是农场的自然增长变得明显吗?似乎有一个明显的步骤使问题变得明显似乎很奇怪。

如果这将成为一个可耻的话"现在情况如何"SharePoint Online的方面。翻译非常有用,而且实施起来非常迅速。

未知说过...

你好

最近在Office 365中遇到了相同的问题。问题我've spotted doesn't come from the image 演绎 itself because SharePoint is realy quick to process the image 演绎s.
I the value for a single image 演绎 was between 5 and 30 milliseconds (SPRequest Duration) to process which is pretty quick and is the same time I got on on premises installation.
我认为问题更多来自ASP.net以及SharePoint / IIS如何组合请求。

在您的痕迹中,据我在屏幕快照中所看到的,您已禁用缓存,这适用于两种情况。第一种是,当用户第一次点击该页面时,否则双色球推荐一注将从本地缓存中加载。
缓存将被忽略的第二种情况是Internet Explorer / Edge无法在HTTPS Pages上本地缓存另一个事实。此浏览器中的所有资产将始终从服务器加载,这会导致页面性能真正下降。

总体而言,目前所有渲染性能都不是最好的。让'希望此问题能尽快解决并更改。

/斯蒂芬

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

嗨,斯蒂芬,

好信息,谢谢。是的,它'绝对是我第一次加载网页 'm专注于此处(正如我试图阐明的那样),因此在禁用缓存的情况下进行了测试。我没'知道与其他浏览器相比,IE / Edge行为存在差异-我'我也会尝试研究这个问题,但是您是怎么想的呢?您还有其他信息吗?

谢谢!

COB。

未知说过...

你好

再次找到了该帖子,Microsoft很好地隐藏了该帖子。有关如何在以下位置找到IE / Edge缓存的信息 返回导航缓存

其中描述了缓存的一般工作方式以及要求。一个条件是:
使用HTTP:协议提供服务(出于安全原因未缓存HTTPS页面)

这与我的评论一致,即Office 365页面以及Edge / IE上的其他页面赢得了'根本不会被缓存。此行为也可以通过IE中的网络跟踪来重现。
Chrome指出了SharePoint的大多数资产'From Cache',Mirosoft Edge再次下载所有内容,并完全忽略缓存。

/斯蒂芬

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

嗨,斯蒂芬,

所以我看着这个,但我不知道'看不到完全一样的东西。据我所知,你'100%的权利是*页面本身*不是从缓存中提供的,而是外部资源(例如CSS和JS文件)是从缓存中提供的。我在IE / Edge开发工具和HttpWatch中对此进行了验证。

你可以看到这个 http://www.milwaukeeticketsblog.com/p/ieedge-network-trace.html

所以,我不 '认为此行为与其他浏览器没有太大不同。但是无论如何,我想主要的是,从广义上讲,绝大多数文件将在非首次页面加载时(如预期的那样)从缓存中提供。

你以为我'我想念一些东西,或者你也认为's the conclusion?

干杯,

COB。

未知说过...

克里斯,你好

再次检查并仔细查看双色球推荐一注。没错,它们现在来自缓存。在Office 365上必须应用了一些更改。几周来,我遇到了与您所描述的相同的问题。
我从Edge到IE 10都进行了检查,无论如何,文件是根据每个请求重新下载的。
我还检查了其他几种浏览器,Mac上的Safari浏览器是下载和渲染页面最快的,时间比其他浏览器快了近50%,而TTFB也好得多。

同样缓慢的TTFB,但主要取决于我尝试过的Tennant。

似乎他们在后台调整了一些内容,因为此时我遇到了一些非常奇怪的麻烦。

I'我们会密切注意这一点,但到目前为止,我可以说,您的解决方案值得在下一个品牌项目或未来的改进中考虑。

/斯蒂芬




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

您好Stefan,

太好了,谢谢您的确认!

干杯,

COB。

DJ王子说过...

我与Microsoft的某人交谈,他们试图在几周前推出针对双色球推荐一注再现错误的修复程序,但没有成功。他们仍在努力。在某些情况下,我们要做的是引用存储在SharePoint中的大缩略图(_w和_jpg前缀)