2013年10月25日,星期五

等待Office 365中的搜索爬网–仔细计划搜索驱动的网站

滴漏在2013年秋季/秋季,如果您’在使用Office 365时,您可能会注意到内容更改(例如新页面和文档)需要一些时间才能出现在搜索结果中。我最近花了一些时间考虑这个问题,因为我和我的团队完成了一个搜索驱动的新闻网站的建设。在此项目上,我们主要针对Office 365开发–我们也使用本地虚拟机,但是由于O365是目标,因此我们会在开发过程中频繁地在其中部署自定义项。

我们注意到“index latency” –新内容出现在搜索索引中所需的时间–比我们在Office 365上预期的要差。我们在不同的订阅级别(例如SharePoint P2,Office 365 E3等)上运行多个租约,我们在所有这些租户中都遇到了问题。有些日子好,有些日子不好。一段难忘的(读的,紧张的)时间,我们度过了“end of sprint demo”-我们的解决方案是在演示前2天进行配置的,这使我们有很多时间来创建测试内容,以使向业务用户展示的演示顺利进行。在演示之前的整整24小时,我们已经完成了页面,文档,图片和视频的添加,并等待主页“light up”因为在Office 365中对内容进行了爬网。

不幸的是,只有一些内容被及时索引了。该演示本身进行得很好,但是可能只是因为一些叙述可以帮助业务用户想象一下‘full’ picture. 总的来说’很难不感到 24小时是等待内容在SharePoint中建立索引的漫长时间! 如今,企业用户期望值更高,并且大多数本地环境’与我们合作使用增量爬网的频率为15或30分钟。

Office 365中的正常时间是多长时间?

糟糕的表现使我们有些惊讶。我和我的同事认为,我们最初阅读到,Office 365中预期最多延迟15分钟,这可能表明SharePoint 2013’s “Continuous Crawl” is used. The Office 365服务描述– Search 现在页面提示不是’确实如此,但是无论如何在后端进行管理,我们当然都没有’期待这么长时间的延迟。一些进一步的挖掘将带您到此知识库文章:

Search doesn't return all results in SharePoint 线上 – KB2008449

“搜索爬网会连续进行,以确保尽快通过搜索结果更改内容。由于需要时间,最近上传的文档可能不会立即显示在搜索结果中。 SharePoint 线上目标 在15分钟到一个小时之间 在搜索结果的上载和可用性之间(也称为索引新鲜度)。在使用环境繁重的情况下,这个时间可以增加到 六个小时.”

好,至少’是正式的东西,即使它’不一定是我们想听到的。但是,为什么有时我们有时会看到比6小时更长的延迟?我向Microsoft提出了一个服务请求以进行查找。

支撑线

简而言之,我没有’无法从Office 365支持获得100%令人满意的答复。最终,听起来这种事情现在在Office 365中是相当正常的。我问其他客户是否正在报告此问题,答案是 “是的,但我们只要求他们再等一天”。嗯,那就好!当然,如果您的网站处理的是对时间敏感的内容(或者您只是在寻找合理的时间范围内要显示在搜索结果中的新内容),’t a great situation.

解决问题

因此,如果您需要考虑其他替代方案:

  • 如果您要处理搜索驱动的功能,是否可以提供相同的功能 询问 而不是 搜索 (例如,如果您不需要跨网站集进行汇总)?
  • 如果您处于混合情况,则功能可以由本地环境提供吗?
  • 您现在是否需要解决方案,还是可以负担得起等待改进的费用? (我个人希望升级到Office 365将来会改善这种情况。)

对于我们来说,实际上这三个都是我们可以使用的选项。在我们的情况下,如果我们需要立即解决方案,那么第二个选项可能是最简单的-为该客户端构建的所有内容都可以部署到Office 365或本地SharePoint。这需要相当多的精心设计(不仅在解决方案方面,而且在部署脚本/过程等方面),但要在混合部署中处于有利位置。

总的来说,让’希望Microsoft在Office 365中进行此工作。’如果我们看到改进,将及时通知您-如果任何人在此方面有任何有用的信息,请随时在下面的评论中分享。

26条评论:

未知说过...

克里斯,好帖子。这确实是一个严重的问题,尤其是在内容搜索Web部件的发行中。

我真的希望这个问题能在客户开始注意到此问题之前尽快解决,不要'不想使用Office 365。

您知道听众每周只编译一次吗?哈哈。很尴尬。

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

@碧玉,

是的,完全同意。我认为目前,关键是要意识到问题(写这篇文章的一个原因)-了解它绝对可以在某些情况下帮助您避开它。

是的,观众编排是'也很棒。由于这个原因,我们不得不使用另一种方法进行个性化。

我谈到的支持技术人员提到了一个事实,即周末在Office 365上当前有几个后台进程。除了受众群体的汇编之外,我认为有时用户配置文件的完全同步可能属于此类,也许还有其他操作。

干杯,

克里斯。

安德斯·拉斯克(Anders Rask)说过...

是的,很遗憾,这几乎反映了我们在SPOL上看到的情况。

我们使用搜索来进行大多数聚合和内容处理,但是由于索引过时,在某些情况下必须使用CQWP。

通常,受众群体可以用您的KQL中的查询参数(例如{User。})代替。

Provision-wize我们已经开发了一个框架(在C#中使用PowerShell cmdlet构建并使用XAML),使它在部署和导入/导出到SPOL或本地时变得透明。

米卡尔·斯文森(Mikael Svenson)说过...

你好
我的消息来源告诉我,他们一直在努力改善Office365所涉及的多租户场景中搜索的工作方式。

我不知道时间表,但是我'确保您今天在365中可能遇到的索引和查询问题将得到解决。请记住,MS是这些天所投注的365,因此他们必须使其发挥作用。

谢谢,
米凯尔

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

@ TGITM /安德斯,

是的,听起来像我们've遵循类似的路径。我们在查询中大量使用{User。},很高兴在Result Script Web部件中能很好地工作-因此在许多情况下需要担心Content Search Web部件。

对于配置,我们的PowerShell脚本接受参数"Online" or "OnPremises"然后从那里做正确的事。娱乐时间!

克里斯。

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

@Mikael,

是的,这也是我的期望-我简直不敢相信他们赢了't solve this soon.

It's good to hear you'我听过这些话:)

克里斯。

未知说过...

抱歉,可能是话题不对,但是...

"对于配置,我们的PowerShell脚本接受参数"Online" or "OnPremises"然后从那里做正确的事。娱乐时间!"

昨天我看了一下Microsoft SharePoint 线上 cmdlet,感到非常失望-我不得不说,这似乎毫无用处。您是否按照TGITM的描述编写并使用了自己的?还是直接在PowerShell中使用CSOM?

未知说过...

这是一个问题,但没有以前那么多。我还必须添加您可以将邮件发送到列表/库或站点级别的SPO中的连续爬网。对于网站和库,它位于列表/库设置中的“高级选项”下;对于网站,它位于“网站设置”,“搜索”和“脱机可用性”中。


也是在英国时间今天凌晨4点,对Search进行了维护,并且在过去的几个月中这种情况经常发生。随着CSPO和跨站点发布等SPO的更改以及新事物的到来,列表搜索中查找字段的数量不仅增加而且还将得到升级。

他们刚刚拆分了共享点实例,所以也许这会尽快改变。

经验法则是,新列或网站最多需要48小时才能显示。新项目可能需要花费几秒钟到15分钟的时间(如果服务器负载过重,则需要更多时间)。并非所有的考虑都太简陋。


问候,

查理·诺曼德说过...

@Jasper有两件事,我认为Content Search Web部件在365中不可用?有hack吗?

@Chris的社区得分统计信息是否也源自搜索或单独的计时器工作? (很累昨天无法在Google上找到答案,不高兴),我们的分数已经过时了几天(可能会加价)。

我们也有一天,我们的农场遭受了48小时的不良表现'Server busy'显然WFE或其他东西掉了下来,但他们花了很长时间才对其进行分类...

是整体'scalable' thing happening?!

菲尔·柴尔德斯说过...

谢谢克里斯-我以为是我!

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

@休,

It'现在还不早说,但是自从我写这篇文章以来,情况可能有所改善。根据我们的经验,"reindex this library"/"reindex this site" options haven'解决了这个问题-在许多情况下,我们在使用此选项后仍需要等待几个小时。

It'如果您确实看到不到15分钟的稳定时间,但是直到昨天(2013年11月6日),我们仍然看到将新内容编入索引的时间仍会延迟几个小时(在已经存在几天/几周的网站中,而不更改架构)。

干杯,

克里斯。

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

@安德鲁,

所有PS + CSOM。我们'我已经非常迷恋那个裂缝了:)

克里斯。

未知说过...

好帖子。

我们在O365和索引编制方面拥有完全相同的经验,并且最终使用CAML进行内容检索。

然而,就我们而言,这带来了其他重大挑战。我们有各种各样的内容细分和安全要求,这意味着我们在大量网站中都有内容,有些用户可以访问一个网站,其他用户可以访问多个网站,并且需要一些汇总视图(所有自定义ui w /响应式设计)。

使用JS CSOM和CAML时,这会带来问题,因为您无法再进行_site级查询_。使用JS CSOM CAML时,必须准确指定要从中检索数据的_where_,这可能会严重影响您构造内容和逻辑IA的方式。

我们必须以一种可以构造查询规则的方式来构造内容,该查询规则隐式地知道针对特定用户或上下文存储内容的位置。虽然有效,但肯定不是'当您知道传统搜索可以完成的工作时,它会非常优雅。

因此,ppl需要了解JS CSOM在CAML中的局限性。

友好的问候,
汤玛士

未知说过...

@克里斯-谢谢,是的,我'我最终选择了CSOM路线进行部署,'不像以前那样糟糕。

不幸的是,我'现在,我确实需要使用搜索。查询自己'不会削减-等待24小时也不会。

Office 365就像想用一只手编织一样。

未知说过...

克里斯,您好,阅读本文可以确认我们不是唯一遇到此问题的人。在我们的情况下,需要花费几天的时间才能重新编制索引。关于字段是否会出现在已爬网字段列表中,添加新的网站栏是非常随机的事情。然后,一旦它出现,最终获得可用的托管财产同样是随机的(几天而不是几小时)。
SharePoint是一个搜索驱动的框架。这远非理想的情况。它将不得不改变。

贾根说过...

克里斯,你好

我发现了类似的问题,并找到了解决之道。

基本上,我的项目没有出现在搜索中已经有一段时间了,后来,我意识到我删除了一些术语,并且引用该术语的列已损坏。我觉得这将是一个问题,尤其是在设置环境时。

一旦我删除了列并要求重新编制索引,项目就会在MS告知的15分钟时间内开始挑选(包括新列)。

唐'不知道这是否是巧合。

干杯,
尖齿

未知说过...

完全同意。微软最好伸出自己的手指。在3项列表中进行搜索,但2小时后仍没有更新。疯。在这种情况下,Search甚至可靠吗?

罗珊说过...

有没有人注意到这一点有所改善?我通常会遇到大约半小时或更短的延迟,但是就在最近,我注意到延迟很多小时。作为SharePoint的新手,还是SharePoint 线上的新手,我们是否知道Office 365爬网计划是什么?演奏时是否有韵律或原因?为什么某些项目在爬网中建立了索引,而其他项目却没有建立索引(例如,同时添加/修改但未包含在同一爬网中的文档)?

匿名 said...

是的,同上...我'从O365测试版开始,我的索引/抓取以及发布/发布和搜索结果之间的延迟存在了一段时间...自O365测试版起...现在我刚刚在上周建立了一个新帐户和新域,'(至少!)花了6天的时间才能获得所有搜索结果,现在这些结果仅是部分结果,并且不包含约4天前更新的信息。

这是一个非常糟糕的经历,并且很难作为顾问来帮助他人使用Office365。我什至还记得前一阵子读过这篇文章,当时遇到了麻烦,只是假设现在必须解决此问题,因为这是只是需要并依赖,它必须存在。它'非常令人沮丧并且非常耗时。

Y'所有这些都具有创造性,有些在此处发布,但我必须仅显示基本页面和页面上的基本内容,甚至不起作用。 (无列自定义。无庞杂的东西。请尽可能多的OOTB。)

ping以获得更多的MSFT牵引力。

布鲁斯说过...

I'我得说这个帖子早在十月'从那时起13指导了我整个SP开发人员的练习方向(所以感谢@Chris!)。我们是否投资于使用搜索/显示模板(MS似乎希望我们这样做)来尽可能地做到这一点,这对于On-Prem来说是不错的选择,但却落在了SPO上,还是我们投资了利用REST作为我们的首选模式对于大多数事情来说,具有最大的可重用性?很高兴我接受了后者。

拉尔斯·林奇说过...

I was also waiting for a new managed property mapping to show up after a 充分 crawl.

重置站点索引可以达到目的: //support.office.com/en-us/article/Manually-request-crawling-and-re-indexing-of-a-site-a-library-or-a-list-9afa977d-39de-4321-b4ca-8c7c7e6d264e?CorrelationId=b019310d-fa92-4bab-9846-1743ae133e41&ui=en-US&rs=en-US&ad=US

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

@Lars,

对,就那个'一个很好的提示,但请记住,它没有't实际上会触发重新抓取(以便搜索获取更改)。你们所有'这样做是*标记*一些要搜索的内容,以便在下一次爬网时确实会对其重新编制索引。

在页面上,您链接到:

"内容将在下一次计划的爬网期间重新索引。"

Still, this can be important as it does allow you to force a 充分 re-index of a site - it's just that you'实际上并没有改变时间。

感谢您的来信!

干杯,

COB。

未知说过...

嗨我们'关于O365的问题,我们仍然面临缓慢爬行的问题。
我确实确实认为这是不可接受的,Microsoft应该在不久的将来解决此问题。
特别是对于用户配置文件,需要很长时间才能获取新属性,并且映射到爬网属性的托管属性需要花费几个小时才能显示。
那里'无法标记用户个人资料或托管属性以进行重新索引:(

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

@让·玛丽(Jean Marie),

同意-用户个人资料/人员数据的索引编制速度仍然对我们来说是一个问题。

干杯,

COB。

阿鲁特说过...

I'过去几个月来,在O365 SharePoint上一直在使用托管元数据字段,Content Search Web部件和搜索优化器。在大多数情况下,爬网似乎每15分钟发生一次,但我'我们花了好几个小时才看到很多情况,有一次,它认为内容显示在内容搜索Web部件中花了将近2天。但是,我'我什至现在都不在乎。

昨天,我观察到CSWP和相关的优化程序中显示的内容消失了,因此我与Microsoft开了一个案子。但是,当我重新索引包含该内容的文档库时,所有这些都在15分钟后开始显示在CSWP中。

对于我来说,搜索索引中的内容将消失似乎很可怕!!!

未知说过...

克里斯,

3年后的2016年11月,问题仍然没有得到解决,也没有达到预期。这太荒谬了。我们仍然需要等待22个小时,才能看到怪异的博客文章。

米卡尔·斯文森(Mikael Svenson),这次您的消息来源告诉您什么?我们要等一个世纪吗?