内容服务器时延确定 【技术领域】
本公开涉及信息检索。
背景技术
响应于由客户端设备在网页的呈现期间生成的内容项请求，显示在网页上的内容可以由一个或多个内容项服务器生成。内容项请求可以关于网页的呈现同步生成。同样，响应于内容项请求所接收的内容项可以关于网页的呈现同步处理。例如，在网页被呈现时，JavaScript可以执行并且从第一内容服务器请求广告。顺次地，第一内容服务器可以从第二内容服务器请求广告。如果广告被同步检索，则网页的呈现被延迟至从内容服务器接收到所请求的广告。一旦广告被接收并呈现，例如被显示在网页上，则恢复网页的剩余部分的呈现。
同步的内容项检索的缺点是：如果内容项服务器慢，则网页的剩余部分的呈现将被延迟。为了减轻同步的内容项处理的潜在影响，网页发布者试图识别延迟源，即可能慢或暂时不可操作的内容项服务器，并且试图计算总时延(latency)时间。然而，为了计算与不同的服务器相关联的时延时间，汇集(compile)来自网页的呈现的多个HTTP请求和响应通常是复杂的任务。例如，由于多个HTTP请求和响应自身不会出现在网页上而由第一内容服务器返回，故其可能看起来陌生。此外，如果确定例如第二内容服务器的特定服务器是延迟源，则向第二内容服务器的操作者说明延迟是困难的。
【发明内容】
根据一些实施方式，确定发布者服务器、第一内容服务器和第二内容服务器的性能。基于发布者服务器性能、第一内容服务器性能和第二内容服务器性能来确定时延时间信息。时延时间信息可以表示加载与发布者服务器、第一内容服务器和第二内容服务器中的每一个相关联的内容的时长。
根据一些实施方式，包含对带有第一行为的脚本的引用的文档的统一资源定位符(URL)可被指定，其中第一参数(argument)被添加到URL。包含对带有第二行为的脚本的引用的文档的URL可被指定，其中第二参数被添加到URL。响应于请求，接收包含脚本的文档。带有第一行为的脚本被执行以确定发布者服务器时延时间，以及带有第二行为的脚本被执行以确定第一内容服务器时延时间。第二内容服务器时延时间基于发布者服务器时延时间和第一内容服务器时延时间来确定。
根据一些实施方式，系统包括处理器，可被配置为确定与发布者服务器、第一内容服务器和第二内容服务器相关联的性能。客户端设备可被配置为基于发布者服务器性能、第一内容服务器性能和第二内容服务器性能来确定时延时间信息，所述时延时间信息表示加载与发布者服务器、第一内容服务器和第二内容服务器中的每一个相关联的内容的时长。根据一些实施方式，系统包括处理器，可被配置为从一个或多个远程位置请求内容，其中内容包括用于确定与请求相关联的时延信息的计算机可执行的指令。可操作地耦接到处理器的界面可被配置为显示时延信息，时延信息包括与和在界面中内容的显示相关联的一个或多个远程位置相关联的时延时间。
根据一些实施方式，请求内容，其中请求是指向内容的统一资源定位符(URL)，并且URL包括添加的参数。所请求的内容可以被加载入第一用户界面中的内容页中。然后可以显示第二用户界面。根据添加到URL的参数，与内容页相关联的一个或多个内容项然后可以在第二用户界面中被显示。另外，与一个或多个内容项相关联的一个或多个属性可以在第二用户界面中被显示。
根据一些实施方式，内容页的第一部分可以在第一用户界面中被加载，其中第一部分包括从发布者服务器接收的内容。然后可以显示第二用户界面。内容页的第二部分可以在第二用户界面中被加载，其中第二部分包括从一个或多个内容服务器接收的一个或多个内容项。另外，与一个或多个内容项相关联的一个或多个属性可以在第二用户界面中被显示。
根据一些实施方式，系统包括发布者服务器，可被配置为将内容页的第一部分传送至客户端设备，其中第一部分包括发布者内容。额外地，一个或多个内容服务器可被配置为将内容页的第二部分传送至客户端设备，其中第二部分包括一个或多个内容项。客户端设备可被配置为在第一用户界面中加载内容页的第一部分、在第二用户界面中加载内容页的第二部分以及在第二用户界面中显示与一个或多个内容项相关联地一个或多个属性。
根据一些实施方式，系统包括客户端设备，被配置为保存从一个或多个内容服务器接收的与内容页相关联的一个或多个内容项的副本。额外地，处理器可被配置为生成用户界面；为一个或多个保存的内容项生成组合的源代码；以及将组合的源代码插入用户界面中。
根据一些实施方式，系统包括发布者服务器，可被配置为捕捉与一个或多个内容项相关联的一个或多个内容项标识。服务器处理器可被配置为生成用户界面；向第一内容服务器生成请求与一个或多个内容项标识相关联的一个或多个内容项的请求；以及将一个或多个内容项呈现在用户界面中。
【附图说明】
图1是用于从内容服务器请求内容的示例系统的框图。
图2是用于确定时延贡献的示例过程。
图3是用于确定时延贡献的另一个示例过程。
图4图示了显示NoFetch模式的输出的示例界面。
图5图示了显示NoRender模式的输出的示例界面。
图6是用于确定时延问题源的示例过程。
图7是用于确定与一个或多个内容服务器相关联的时延时间的示例过程。
图8是用于确定与一个或多个内容服务器相关联的时延时间的另一个示例过程。
图9是用于确定与一个或多个内容服务器相关联的时延时间的另一个示例过程。
图10是示例用户界面的图示。
【具体实施方式】
图1是用于从一个或多个内容服务器请求内容的示例系统10的框图。在一个实施方式中，内容可以包括广告，以及内容服务器可以是内容服务器。也可以请求不同类型的内容。
在一个实施方式中，客户端系统100被配置为查看通过例如因特网的网络可访问的内容(例如访问网页)。客户端系统100可以是例如web浏览器或者执行网络导航软件的计算设备等。由客户端系统100访问的web地址(例如统一资源定位符(URL))可以被解析以识别托管对应的网页的发布者102，例如服务器。在这个示例中，客户端系统100可以为网页内容106将网页内容请求104发送给发布者102。发布者102响应于请求将网页内容106作为例如包含JavaScript的HTML文档提供给客户端系统100。网页内容106可以包括一个或多个内容展示。在一个实施方式中，内容展示可以包括用于待由内容服务器派发的广告的广告槽段(slot)。其它的内容展示也可以被使用。
由发布者102提供的网页内容106包括对一组指令108的引用。在一个实施方式中，指令108包括用于呈现并展示所请求的内容例如广告的存储指令108a、定时指令108b和请求指令108c。在一个实施方式中，指令108由例如内容服务器的第一内容服务器134提供，并且被存储在客户端系统100处，诸如与web浏览器相关联的缓存中。
网页内容106可以定义被配置为显示来自一个或多个内容服务器的内容的内容槽段112-120。在一个实施方式中，内容槽段112-120是在HTML标记内定义的广告槽段。指令108生成被发出来请求内容以填充内容槽段112至120的内容请求122-130。在一个实施方式中，请求122至130被存储在诸如缓冲区132的数据存储132中，并且然后以一个或多个请求136发送给内容服务器134。
在一个实施方式中，第一内容服务器134处理所接收的单个或组合请求136并且将所识别的内容138返回给客户端系统100。在另一个实施方式中，第一内容服务器134处理来自客户端系统100的所接收的单个或组合请求136，并且将组合响应137发送给客户端系统100。例如，响应可以以HTML或JavaScript形式。从第一内容服务器134到客户端系统100的组合响应137可以指示客户端系统100将请求内容项的一个或多个请求140发送给第二内容服务器142。第二内容服务器142然后可以例如将所识别的内容144返回给客户端系统100。所识别的内容138和/或144然后可以作为发布者的网页的一部分被显示在对应的内容槽段中，例如内容槽段112、114和116。
第一内容服务器134的示例可以包括GoogleTM内容服务器。可以向GoogleTM内容服务器发出请求以用广告填充网页上的内容槽段。顺次地，GoogleTM内容服务器可以识别并提供广告，或者GoogleTM内容服务器可以从第二内容服务器142即第三方内容服务器请求广告。虽然仅提及两个内容服务器134和142，但是多于两个内容服务器可以向单个网页提供内容。
在客户端系统100从发布者102、第一内容服务器134和/或第二内容服务器142请求内容时，可能发生时延延迟。例如，时延延迟可能与各种问题相关，诸如慢的网络速度、发布者服务器102慢、第一内容服务器134慢、和/或第二内容服务器142慢。客户端系统100的用户可能只能看到网页加载所花费的总时延时间。因此，确定归因于发布者服务器102、第一内容服务器134和第二内容服务器142的时延延迟贡献可能很难说明。
如上面的示例中所描述，显示网页的总时延时间(L)可能归因于网络的速度，即包括网络时延时间的发布者服务器102速度(L1)、第一内容服务器134速度(L2)和第二内容服务器142速度(L3)。因此，作为示例，对于总时延时间的计算可以由L＝L1+L2+L3确定。
参考图2，根据一些实施方式，确定时延贡献的示例过程200从确定发布者服务器的性能(步骤202)开始。为了确定发布者服务器102的性能，可以通过将参数(或其它指示符)与请求包括在一起从发布者服务器102发出对内容的请求。例如，可以将参数“google_nofetch”添加到网页内容位置的URL如下：http://www.webpage.com？google_nofetch，以实现NoFetch模式。
可以从内容位置接收与所请求的URL相关联的文档。文档可以包括网页内容、媒体、文本、可下载的文件等。与发布者服务器102相关联的性能即时延时间可以被确定。在一些实施方式中，在网页内容106内的内容派发(即JavaScript)标记实现诊断逻辑。例如，在网页内容106内的脚本文件可以测试诸如与发布者服务器102相关联的时延时间的各种情况，以及将信息写入用户界面。
在NoFetch模式中，在网页内容106内的脚本文件可以防止从第一内容服务器134检索内容项，即向第一内容服务器134发出的对广告的请求。例如，传送到第一内容服务器134的任何请求可以以NO-OP指令替代，使得其(除生成调试跟踪外)什么也不做。因此，以NoFetch模式运行可以确立发布者服务器102对于网页的基准性能，即如果发布者未将任何广告添加到网页则用户将体验到的NoFetch时延时间(L1)。
接着，与第一内容服务器134相关联的性能被确定(步骤204)。为了确定第一内容服务器134的性能，可以将参数(或其它指示符)与网页位置的URL包括在一起。例如，可以将参数“google_norender”添加到网页内容位置的URL如下：http://www.webpage.com？google_norender，以实现NoRender模式。
在一些实施方式中，在网页内容106内的内容派发(例如JavaScript)标记实现诊断逻辑。例如，在网页内容106内的脚本文件可以测试诸如与第一内容服务器134相关联的性能即时延时间的各种情况，以及将信息写入用户界面。
在NoRender模式中，在网页内容106内的脚本文件可以从第一内容服务器134返回内容项，即可以将请求发送至第一内容服务器134以检索广告。然而，在第一内容服务器134检索广告后，脚本文件可以防止广告在网页上呈现。例如，与内容槽段112、114和116中的广告相关联的代码被显示，而不是在网页上的内容槽段112、114和116中呈现实际广告。因此，运行NoRender模式可以确立用于第一内容服务器134检索广告但并不呈现广告的性能即时延时间。与第一内容服务器134相关联的时延时间可以通过从NoRender时延时间减去NoFetch时延时间来计算，即L2＝NoRender时延时间-NoFetch时延时间(L1)。
在步骤206中，第二内容服务器142的性能可以被确定。为了确定第二内容服务器142的性能，可以通过在不带参数的情况下请求网页内容位置的URL如下http://www.webpage.com，来发出对第一内容服务器134的内容的请求。与请求并呈现URL相关联的总页面加载时间等于总时延时间(L)。因此，与第二内容服务器142相关联的时延时间可以通过从总时延时间减去NoRender时延时间来计算，即，L3＝总时延时间(L)-NoRender(L2)。
在发布者服务器、第一内容服务器和第二内容服务器的性能被确定后，时延时间信息的确定可以基于发布者服务器性能、第一内容服务器性能和第二内容服务器性能来确定(步骤208)。时延时间信息可以表示加载与发布者服务器、第一内容服务器和第二内容服务器中的每一个相关联的内容的时长。例如，可以产生用户界面，以及与归因于不同组件的时延时间有关的信息被写入该用户界面。在一些实施方式中，用户界面由提供单独浏览器窗口的JavaScript代码创建。
图3是用于确定时延贡献的另一个示例过程300。用于确定时延贡献的示例过程300从以下开始：提交统一资源定位符(URL)以请求包含对脚本的引用的文档，该请求包括添加到该URL的第一参数(步骤302)。例如，可以将第一参数“google_nofetch”添加到网页内容位置的URL如下：http://www.webpage.com？google_nofetch，以实现NoFetch模式。
接着，过程300可以提交URL以请求包含对脚本的引用的文档，该请求包括添加到该URL的第二参数(步骤304)。例如，可以将参数“google_norender”添加到网页内容位置的URL如下：http://www.webpage.com？google_norender，以实现NoRender模式。
响应于步骤302和304中的请求，可以接收包含脚本的文档(步骤306)。在接收文档后，可以根据第一参数和第二参数来执行脚本以确定发布者服务器时延时间和第一内容服务器时延时间(步骤308)。例如，脚本可以根据第一参数执行NoFetch模式，以及脚本可以根据第二参数执行NoRender模式。基于发布者服务器时延时间和第一内容服务器时延时间，第二内容服务器时延时间可以被确定(步骤310)。
图4图示了显示带有执行NoFetch模式的第一行为的脚本的输出的示例界面400。图4的列402指示与所执行的NoFetch模式的指令相关联的时延时间。例如，时延时间被展示为随着脚本执行而增加的运行时间。图4的列404提供用于由执行NoFetch模式的脚本正处理的指令的消息类型。图4的列406提供指示由执行NoFetch模式的脚本正处理的指令的摘要消息。在NoFetch模式中，执行在网页内容106内的脚本文件可以防止从一个或多个内容服务器检索广告。如图4的408处所指示，脚本制止了对广告的获取；因此，可以将NoFetch模式中的时延时间信息与发布者服务器相关联。
在执行带有第一行为的脚本后，可以执行带有第二行为的脚本以确定第一内容服务器时延时间(步骤310)。带有第二行为的脚本可以执行NoRender模式。图5图示了显示NoRender模式的输出的示例界面500。图5的列502指示与执行NoRender模式的脚本相关联的时延时间。例如，时延时间被展示为随着脚本执行而增加的运行时间。图5的列504提供用于由执行NoRender模式的脚本正处理的指令的消息类型。图5的列506提供指示由执行NoRender模式的脚本正处理的指令的摘要消息。运行NoRender模式可以确立用于第一内容服务器134检索广告但并不呈现广告的性能，如图5的508处所显示。与第一内容服务器134相关联的时延时间可以通过从NoRender时延时间减去NoFetch时延时间来计算，即L2＝NoRender时延时间-NoFetch时延时间(L1)。
在以NoFetch和NoRender模式运行文档后，可以基于发布者服务器时延时间和第一内容服务器时延时间来确定第二内容服务器时延时间。为了确定第二内容服务器142的性能，可以通过在不带参数的情况下将网页内容位置的URL提交至发布者服务器102如下http://www.webpage.com，来发出对第一内容服务器134的内容的请求。与请求并呈现URL相关联的总页面加载时间基本上等于总时延时间(L)。因此，与第二内容服务器142相关联的时延时间可以通过从总时延时间减去NoRender时延时间来计算，即，L3＝总时延时间(L)-NoRender时延时间(L2)。
图6是用于确定时延影响源的示例过程600。基于对与发布者服务器、第一内容服务器和第二内容服务器相关联的时延时间的确定，与内容页相关联的慢加载时间源可以被确定。如果在判定步骤602中确定L1慢，则时延源最可能归因于发布者服务器102(步骤604)。然而，如果在判定步骤602中确定L1快，则过程600前进到判定步骤606。在判定步骤606中，如果确定L2慢，则时延源最可能归因于第一内容服务器134(步骤608)。如果在判定步骤606中确定L2快，则过程600前进到判定步骤610。在判定步骤610中，如果确定L3快，则对于内容页加载时间的时延可以被认为很少(L1、L2和L3均被确定为快)(步骤612)。然而，如果在判定步骤610中确定L3慢，则时延源最可能归因于第二内容服务器142(步骤614)。
基于在上面描述的示例过程，可以确定的是时延源最可能归因于第二内容服务器142。基于该确定，在图7中图示了用于确定与诸如第二内容服务器142的一个或多个内容服务器相关联的时延时间的示例过程700。首先，可以请求内容，其中请求是指向内容的统一资源定位符(URL)，URL包括添加的参数(步骤702)。响应于请求所接收的内容可以被加载入第一用户界面中的内容页中(步骤704)。在一个实施方式中，被加载入内容页的内容可以包括内容的第一部分，其中内容的第一部分仅包括来自发布者服务器102的内容。
接着，第二用户界面可以被显示(步骤706)。为了显示第二用户界面，可以请求包含脚本的文档，其中请求包括指示符。例如，请求可以是指向接收文档的统一资源定位符(URL)以及指示符是被添加到URL的参数。然后例如响应于请求，文档可以被接收。然后响应于指示符的接收，脚本可以被执行来显示第二用户界面。例如，第二用户界面可以是与显示内容页的浏览器窗口分立的浏览器窗口。
在另一个实施方式中，第一和第二用户界面可以在同一界面中显示。第一和第二用户界面可以由常见客户端设备上的常见浏览器呈现。例如，第一和第二用户界面可以在客户端设备上执行的单个用户界面中呈现，诸如浏览器窗口。
随后，根据添加到URL的参数可以在第二用户界面中显示与内容页相关联的例如广告的一个或多个内容项(步骤708)。另外，可以显示第二用户界面中的每一个内容项的一个或多个属性(步骤710)。例如，被显示的属性可以包括与每一个内容项相关联的加载时间和总加载时间。
在一个实施方式中，显示一个或多个内容项可以通过利用客户端侧实施方式来完成。例如，待被插入内容项槽段中的一个或多个内容项的副本可以从一个或多个内容服务器被接收并保存。然后可以向内容页注册上载回调。在上载回调期间，显示第二用户界面，以及在内容项槽段中进行扫描。在内容项槽段中进行扫描后，与内容项相关联的例如HTML代码的所有代码可以被组合。组合的HTML代码然后可以被插入第二用户界面中，并且所有的内容项可以被生成。
在另一个实施方式中，在第二用户界面中显示一个或多个内容项可以通过利用服务器侧实施方式来完成。例如，可以利用JavaScript捕捉与一个或多个内容项相关联的一个或多个内容项标识。然后可以打开第二用户界面，以及通过利用一个或多个广告标识向一个或多个内容服务器发出对一个或多个内容项的请求。从一个或多个内容服务器接收的一个或多个内容项然后可以例如在第二用户界面中被呈现。在一个实施方式中，与每一个内容项相关联的加载时间可以在第二用户界面中被显示。在一个实施方式中，总加载时间可以在第二用户界面中被显示。
在一些实施方式中，与第二用户界面相关联的源代码可以被保存。例如，用户可以查看并保存第二用户界面中的页面的源代码。保存源代码在向为时延负责的内容服务器的操作者说明一个或多个内容项的时延时是有用的。具体地，源代码可以被用来准确找出哪些内容项即广告在加载时间中产生最大延迟。源代码可以例如被直接以电子邮件形式发送给内容服务器的操作者。源代码然后可以例如在诸如浏览器的用户界面中被加载以说明关于特定内容项的时延。
在图8中图示了用于确定与诸如第二内容服务器142的一个或多个内容服务器相关联的时延时间的另一个示例过程800。在确定与内容页相关联的时延源后，内容页的第一部分可以在第一用户界面中被加载，其中第一部分包括从发布者服务器接收的内容(步骤802)。例如，内容的第一部分可以不包括来自一个或多个内容服务器的一个或多个内容项。
接着，第二用户界面可以被显示(步骤804)。随后，与内容页的第二部分相关联的源代码即HTML代码可以在第二用户界面中被显示，其中第二部分包括从一个或多个内容服务器接收的一个或多个内容项(步骤806)。为了在第二用户界面中显示与一个或多个内容项相关联的例如HTML代码的源代码，可以请求包含脚本的文档，其中请求包括指示符。例如，请求可以是指向接收文档的统一资源定位符(URL)，以及指示符是被添加到URL的参数。然后例如响应于请求，文档可以被接收。然后响应于指示符的接收，脚本可以被执行来显示包括与一个或多个内容项相关联的源代码的第二用户界面。
例如，参数“google_capture_norender”可以被添加到网页内容位置的URL如下http://www.webpage.com？google_capture_norender。作为响应，包含与一个或多个内容项相关联的源代码的第二用户界面可以被显示。源代码然后可以例如被复制(步骤808)，被粘贴入编辑器中(步骤810)，以及然后被保存至文件(步骤812)，诸如本地HTML文件。此后诸如浏览器或其它用户界面的用户界面可以被利用来打开例如本地HTML文件的文件，其包含与一个或多个内容项相关联的源代码(步骤814)。当文件被打开时，文件可以在用户界面中呈现与内容页相关联的一个或多个内容项(步骤816)。另外，与一个或多个内容项相关联的一个或多个属性可以在用户界面中被显示(步骤818)。例如，属性可以包括与每一个内容项相关联的加载时间和与一个或多个内容项相关联的总加载时间。图9是用于确定与诸如第二内容服务器142的一个或多个内容服务器相关联的时延时间的另一示例过程900。过程900从以下开始：在第一用户界面中加载内容页的第一部分，其中第一部分包括从发布者服务器接收的内容(步骤902)。例如，被加载入第一用户界面中的内容页的部分可以不包括来自一个或多个内容服务器的内容。接着，第二用户界面被显示(步骤904)。例如，第二用户界面可以是除第一用户界面外的被显示的窗口，诸如弹出窗口。
内容页的第二部分然后可以例如在第二用户界面中被显示，其中第二部分包括从一个或多个内容服务器接收的一个或多个内容项(步骤906)。另外，与一个或多个内容项相关联的一个或多个属性可以在第二用户界面中被显示(步骤908)。例如，属性可以包括与每一个内容项相关联的加载时间和与一个或多个内容项相关联的总加载时间。
图10是如在上面的过程中所描述的示例第二用户界面1000的图示。如所述，与一个或多个内容项相关联的一个或多个属性可以在第二用户界面1000中被显示。在一个实施方式中，与每一个内容项相关联的位置和尺寸信息1002可以在第二用户界面1000中被显示。在另一个实施方式中，内容项1004可以在第二用户界面1000中被显示。在另一个实施方式中，与每一个广告相关联的加载时间1006可以在第二用户界面1000中被显示。例如，可以将单个加载时间1006与和位置和尺寸信息1002一起显示的广告1004相关联。在另一个实施方式中，总加载时间1006可以在第二用户界面1000中被显示。
在本专利文档中描述的装置、方法、流程图和结构化框图可以在包括程序代码的计算机处理系统中实现，该程序代码包括由计算机处理系统可执行的程序指令。还可以使用其它实施方式。另外，还可以利用在本专利文档中描述的流程图和结构化框图来实现对应的软件结构和算法以及其等价物，所述流程图和结构化框图描述了特定方法和/或支持步骤的对应动作和支持公开的结构化装置的对应功能。
所写的描述阐明了本发明的最佳模式并且提供了描述本发明的示例使得本领域的普通技术人员能够制造和使用本发明。所写的描述并非将本发明限制在所阐明的精确的术语。因此，尽管已经参考上面阐明的示例详细描述了本发明，但是本领域的普通技术人员可以在不背离本发明的范围的情况下，对示例进行变更、修改和变化。