Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
CONTENT SERVER LATENCY DETERMINATION
FIELD
This disclosure relates to information retrieval.
BACKGROUND
Content displayed on a web page can be generated by one or more content item
servers in response to content item requests that are generated during the
rendering of the
web page by a client device. The content item requests can be generated
synchronously with
respect to the rendering of the web page. Likewise, the content items received
in response to
the content item requests can be processed synchronously with respect to the
rendering of the
web page. For example, when a web page is rendered, JavaScript may execute and
request
an advertisement from a first content server. In turn, the first content
server may request an
advertisement from a second content server. If the advertisement is retrieved
synchronously,
the rendering of the web page is delayed until a requested advertisement is
received from a
content server. Once the advertisement is received and rendered, e.g.,
displayed on the web
page, the rendering of the remainder of the web page resumes.
A drawback of synchronous content item retrieval is that if a content item
server is
slow, then the rendering of the remainder of the web page will be delayed. To
mitigate the
potential effects of synchronous content item processing, web page publishers
attempt to
identify the source of the delay, i.e., the content item server that may be
slow or temporarily
inoperable, and to calculate the total latency times. However, it is often a
complex task to
compile the multiple HTTP requests and responses from the rendering of a web
page in order
to calculate the latency times associated with the different servers. For
example, the multiple
HTTP requests and responses can look unfamiliar, as they do not appear on the
web page
itself, but are returned by the first content server. Furthermore, if it is
determined that a
particular server, e.g., the second content server, is the source of the
delay, it is difficult to
demonstrate the delay to the operator of the second content server.
SUMMARY
According to some implementations, a performance of a publisher server, a
first
content server, and a second content server is determined. Latency time
information is
determined based on the publisher server performance, the first content server
performance,
1
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
and the second content server performance. The latency time information can
represent a
length of time to load content associated with each of the publisher server,
the first content
server, and the second content server.
According to some implementations, a Uniform Resource Locator (URL) of a
document containing a reference to a script with a first behavior can be
specified, wherein a
first argument is added to the URL. The URL of the document containing a
reference to the
script with a second behavior can be specified, wherein a second argument is
added to the
URL. The document containing the script is received in response to the
requests. The script
with the first behavior is executed to determine a publisher server latency
time, and the script
with the second behavior is executed to determine a first content server
latency time. A
second content server latency time is determined based on the publisher server
latency time
and the first content server latency time.
According to some implementations, a system includes a processor configurable
to
determine a performance associated with a publisher server, a first content
server, and a
second content server. A client device is configurable to determine latency
time information
based on the publisher server performance, the first content server
performance, and the
second content server performance, the latency time information representing a
length of time
to load content associated with each of the publisher server, the first
content server, and the
second content server. According to some implementations, a system includes a
processor
configurable to request content from one or more remote locations, wherein the
content
includes computer executable instructions to determine latency information
associated with
the request. An interface that is operatively coupled to the processor is
configurable to
display the latency information, the latency information including latency
times associated
with the one or more remote locations associated with the display of the
content in the
interface.
According to some implementations, content is requested, wherein the request
is a
Uniform Resource Locator (URL) directed to the content, and the URL includes
an added
argument. The requested content can be loaded into a content page in a first
user interface.
A second user interface can then be displayed. One or more content items
associated with the
content page can then be displayed in the second user interface in accordance
with the
argument added to the URL. In addition, one or more attributes associated with
the one or
more content items can be displayed in the second user interface.
According to some implementations, a first portion of a content page can be
loaded in
a first user interface, where the first portion includes content received from
a publisher server.
2
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
A second user interface can then be displayed. A second portion of the content
page can be
loaded in the second user interface, where the second portion includes one or
more content
items received from one or more content servers. In addition, one or more
attributes
associated with the one or more content items can be displayed in the second
user interface.
According to some implementations, a system includes a publisher server
configurable to transmit a first portion of a content page to a client device,
wherein the first
portion includes publisher content. Additionally, one or more content servers
can be
configurable to transmit a second portion of the content page to the client
device, where the
second portion includes one or more content items. The client device can be
configurable to
load the first portion of the content page in a first user interface, load the
second portion of
the content page in a second user interface, and display one or more
attributes associated with
the one or more content items in the second user interface.
According to some implementations, a system includes a client device
configurable to
save a copy of one or more content items associated with a content page
received from one or
more content servers. Additionally, a processor is configurable to generate a
user interface;
generate a combined source code for the one or more saved content items; and
insert the
combined source code into the user interface.
According to some implementations, a system includes a publisher server
configurable to capture one or more content item identifications associated
with one or more
content items. A server processor is configurable to generate a user
interface; generate a
request to a first content server requesting the one or more content items
associated with the
one or more content item identifications; and render the one or more content
items into the
user interface.
BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 is a block diagram of an example system for requesting content from a
content
server.
Fig. 2 is an example process for determining latency contributions.
Fig. 3 is another example process for determining latency contributions.
Fig. 4 illustrates an example interface displaying the output of NoFetch mode.
Fig. 5 illustrates an example interface displaying the output of NoRender
mode.
Fig. 6 is an example process for determining a source of latency issues.
Fig. 7 is an example process for determining the latency time associated with
one or
more content servers.
3
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
Fig. 8 is another example process for determining the latency time associated
with one
or more content servers.
Fig. 9 is another example process for determining the latency time associated
with one
or more content servers.
Fig. 10 is an illustration of an example user interface.
DETAILED DESCRIPTION
Fig. 1 is a block diagram of an example system 10 for requesting content from
one or
more content servers. In one implementation, the content may include
advertisements, and
the content servers can be content servers. Different types of content can
also be requested.
In one implementation, a client system 100 is configured to view content
(e.g., visit
web pages) accessible through a network, e.g., the Internet. The client system
100 can, for
example, be a web browser, or a computing device executing network navigation
software,
etc. A web address (e.g., Uniform Resource Locator (URL)) visited by the
client system 100
can be resolved to identify a publisher 102, e.g. a server, hosting a
corresponding web page.
In this example, a client system 100 can send a web page content request 104
to the publisher
102 for the web page content 106. The publisher 102, in response to the
request, provides the
web page content 106 to the client system 100 as, e.g., an HTML document
containing
JavaScript. The web page content 106 can include one or more content
presentations. In an
implementation, the content presentations can include advertisement slots for
advertisements
to be served by a content server. Other content presentations can also be
used.
The web page content 106 provided by the publisher 102 includes a reference to
a set
of instructions 108. In an implementation, the instructions 108 include
storing instructions
108a, timing instructions 108b and request instructions 108c that are used to
render and
present the requested content, e.g., advertisements. In an implementation, the
instructions
108 are provided by a first content server 134, e.g., a content server, and
are stored at the
client system 100, such as in a cache associated with a web browser.
The web page content 106 can define content slots 112 - 120 that are
configured to
display content from the one or more content servers. In an implementation,
the content slots
112 - 120 are advertisement slots that are defined within HTML tags. The
instructions 108
generate content requests 122 - 130 that are issued to request content to fill
the content slots
112 to 120. In an implementation, the requests 122 to 130 are stored in a data
store 132, such
as a buffer 132, and then sent to the content server 134 in one or more
requests 136.
4
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
In an implementation, the first content server 134 processes the received
individual or
combined requests 136 and returns identified content 138 to the client system
100. In another
implementation, the first content server 134 processes the received individual
or combined
requests 136 from the client system 100 and sends a combined response 137 to
the client
system 100. For example, the response can be in HTML or JavaScript. The
combined
response 137 to the client system 100 from the first content server 134 can
instruct the client
system 100 to send one or more requests 140 to a second content server 142
requesting
content items. The second content server 142 can then, for example, return
identified content
144 to the client system 100. The identified content 138 and/or 144 can then
be displayed as
part of the publisher's web page in the corresponding content slots, e.g.,
content slots 112,
114 and 116.
An example of the first content server 134 can include a GoogleTM content
server.
Requests can be made to the GoogleTM content server to fill content slots on
the web page
with advertisements. In turn, the GoogleTM content server can identify and
provide
advertisements, or the GoogleTM content server can requests advertisements
from the second
content server 142, i.e., a third party content server. While reference is
made to only two
content servers 134 and 142, more than two content servers can provide content
to a single
web page.
When the client system 100 requests content from the publisher 102, the first
content
server 134, and/or the second content server 142, latency delays can occur.
For example, the
latency delays can be related to a variety of issues, such as a slow network
speed, the
publisher server 102 is slow, the first content server 134 is slow, and/or the
second content
server 142 is slow. A user of the client system 100 can only see a total
latency time it takes
for the web page to load. Therefore, determining the latency delay
contributions attributed to
the publisher server 102, first content server 134, and second content server
142 can be
difficult to demonstrate.
As described in the example above, a total latency time (L) to display a web
page can
be attributed to the speed of the network, the publisher server 102 speed
(L1), which includes
network latency time, the first content server 134 speed (L2), and the second
content server
142 speed (L3). Therefore, by way of example, the calculation for the total
latency time can
be determined by L = L1 + L2 + U.
With reference to Fig. 2, in accordance with some implementations, an example
process 200 to determine latency contributions begins with determining a
performance of a
publisher server (step 202). To determine the performance of the publisher
server 102, a
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
request for content from a publisher server 102 can be made by including an
argument (or
other indicator) with the request. For example, the argument "google_nofetch"
can be added
to the URL of a web page content location as follows:
http://www.webpage.com?googlenofetch to implement a NoFetch mode.
A document associated with the requested URL can be received from a content
location. The document can include web page content, media, text, a
downloadable file, etc.
The performance, i.e., a latency time, associated with the publisher server
102 can be
determined. In some implementations, the content serving (e.g., JavaScript)
tags within the
web page content 106 implement diagnostic logic. For example, a script file
within the web
page content 106 can test for various conditions, such as the latency time
associated with the
publisher server 102, and write information to a user interface.
In a NoFetch mode, a script file within the web page content 106 can prevent
the
retrieval of content items from the first content server 134, i.e., requests
made to the first
content server 134 for advertisements. For example, any requests transmitted
to the first
content server 134 can be replaced with a NO-OP instruction, such that they do
nothing
(other than generating a debug trace). Therefore, running in NoFetch mode can
establish a
baseline performance for the publisher server 102 for a web page, i.e., a
NoFetch latency time
(L1) a user would experience if the publisher did not add any advertisements
to the web page.
Next, a performance associated with the first content server 134 is determined
(step
204). To determine the performance of the first content server 134, an
argument (or other
indicator) can be included with the URL of a web page location. For example,
the argument
"googlenorender" can be added to the URL of a web page content location as
follows:
http://www.webpage.com?google_norender to implement a NoRender mode.
In some implementations, the content serving (e.g., JavaScript) tags within
the web
page content 106 implement diagnostic logic. For example, a script file within
the web page
content 106 can test for various conditions, such as the performance, i.e.,
the latency time,
associated with the first content server 134, and write information to a user
interface.
In a NoRender mode, a script file within the web page content 106 can return
content
items from the first content server 134, i.e., requests can be sent to first
content server 134 to
retrieve advertisements. However, after the first content server 134 retrieves
the
advertisements, the script file can prevent the advertisements from being
rendered on the web
page. For example, instead of rendering the actual advertisement on the web
page in content
slots 112, 114 and 116, the code associated with the advertisement in the
content slots 112,
114 and 116 is displayed. Therefore, running the NoRender mode can establish a
6
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
performance, i.e., a latency time, for a first content server 134 to retrieve
the advertisements,
but not render them. The latency time associated with the first content server
134 can be
calculated by subtracting the NoFetch latency time from the NoRender latency
time, i.e., L2
= NoRender latency time - NoFetch latency time (L1).
In step 206, a performance of the second content server 142 can be determined.
To
determine the performance of the second content server 142, a request for
content from the
first content server 134 can be made by requesting the URL of a web page
content location,
without an argument, as follows: http://www.webpage.com. The total page load
time
associated with requesting and rendering the URL is equivalent to the total
latency time (L).
Thus, the latency time associated with the second content server 134 can be
calculated by
subtracting the NoRender latency time from the total latency time, i.e., L3 =
total latency
time (L) - NoRender (L2).
After the performance of the publisher server, first content server, and
second content
server are determined, a determination of latency time information can be
determined based
on the publisher server performance, the first content server performance, and
the second
content server performance (step 208). The latency time information can
represent a length
of time to load content associated with each of the publisher server, the
first content server,
and the second content server. For example, a user interface can be spawned
and information
regarding the latency times attributed to the different components is written
to the user
interface. In some implementations, the user interface is created by
JavaScript code that
provides a separate browser window.
Fig. 3 is another example process 300 for determining latency contributions.
The
example process 300 for determining the latency contributions begins with
submitting a
Uniform Resource Locator (URL) to request a document containing a reference to
a script,
the request including a first argument added to the URL (step 302). For
example, the first
argument "googlenofetch" can be added to the URL of a web page content
location as
follows: http://www.web page.com?googlenofetch to implement a NoFetch mode.
Next, the process 300 can submit the URL to request the document containing a
reference to the script, the request including a second argument added to the
URL (step 304).
For example, an argument "googlenorender" can be added to the URL of a web
page
content location as follows: http://www.web page.com?googlenorender to
implement a
NoRender mode.
In response to the requests in steps 302 and 304, the document containing the
script
can be received (step 306). After receiving the document, the script can be
executed to
7
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
determine the publisher server latency time and the first content server
latency time in
accordance with the first argument and the second argument (step 308). For
example, the
script can execute the NoFetch mode in accordance with the first argument, and
the script can
execute the NoRender mode in accordance with the second argument. Based on the
publisher
server latency time and the first content server latency time, a second
content server latency
time can be determined (step 310).
Fig. 4 illustrates an example interface 400 displaying the output of the
script with the
first behavior executing the NoFetch mode. Column 402 of Fig. 4 indicates the
latency time
associated with the executed instructions of the NoFetch mode. For example,
the latency
time is presented as a running time that increases as the script executes.
Column 404 of Fig.
4 provides a message type for the instructions that are being processed by the
script executing
the NoFetch mode. Column 406 of Fig. 4 provides a summary message indicating
the
instructions that are being processed by the script executing the NoFetch
mode. In NoFetch
mode, the executing script file within the web page content 106 can prevent
the retrieval of
advertisements from the one or more content servers. As indicated at 408 of
Fig. 4, the script
suppresses the fetching of the ads; therefore, the latency time information in
NoFetch mode
can be associated with the publisher server.
After executing the script with the first behavior, the script with the second
behavior
can be executed to determine the first content server latency time (step 310).
The script with
the second behavior can execute the NoRender mode. Fig. 5 illustrates an
example interface
500 displaying the output of NoRender mode. Column 502 of Fig. 5 indicates the
latency
time associated with the script executing the NoRender mode. For example, the
latency time
is presented as a running time that increases as the script executes. Column
504 of Fig. 5
provides a message type for the instructions that are being processed by the
script executing
the NoRender mode. Column 506 of Fig. 5 provides a summary message indicating
the
instructions that are being processed by the script executing the NoRender
mode. Running
the NoRender mode can establish a performance for a first content server 134
to retrieve the
advertisements, but not render them, as displayed at 508 of Fig. 5. The
latency time
associated with the first content server 134 can be calculated by subtracting
the NoFetch
latency time from the NoRender latency time, i.e., L2 = NoRender latency time -
NoFetch
latency time (L 1).
After running the document in NoFetch and NoRender mode, the second content
server latency time can be determined based on the publisher server latency
time and the first
content server latency time. To determine the performance of the second
content server 134,
8
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
a request for content from the first content server 134 can be made by
submitting the URL of
a web page content location to the publisher server 102, without an argument,
as follows:
http://www.web page.com. The total page load time associated with requesting
and
rendering the URL is substantially equivalent to the total latency time (L).
Thus, the latency
time associated with the second content server 134 can be calculated by
subtracting the
NoRender latency time from the total latency time, i.e., L3 = total latency
time (L) -
NoRender latency time (L2).
Fig. 6 is an example process 600 for determining the source of a latency
effect. Based
on the determination of the latency times associated with a publisher server,
a first content
server, and a second content server, the source of the slow load times
associated with a
content page can be determined. If L1 is determined to be slow in decision
step 602, then the
source of the latency is most likely attributed to the publisher server 102
(step 604).
However, if L1 is determined to be fast in decision step 602, the process 600
moves to
decision step 606. In decision step 606, if L2 is determined to be slow, then
the source of the
latency is most likely attributed to the first content server 134 (step 608).
If L2 is determined
to be fast in decision step 606, the process 600 moves to decision step 610.
In decision step
610, if L3 is determined to be fast, latency with the content page load time
can be deemed as
low (L1, L2, and L3 are all determined to be fast) (step 612). However, if L3
is determined
to be slow in decision step 610, then the source of the latency is most likely
attributed to the
second content server 142 (step 614).
Based on the example processes described above, it can be determined that the
source
of the latency is most likely attributed to the second content server 142.
Based on this
determination, an example process 700 for determining the latency time
associated with one
or more content servers, such as the second content server 142, is illustrated
in Fig. 7. First,
content can be requested, wherein the request is a Uniform Resource Locator
(URL) directed
to the content, the URL comprising an added argument (step 702). The content
received in
response to the request can be loaded into a content page in a first user
interface (step 704).
In one implementation, the content loaded into the content page can includes a
first portion of
content, where the first portion of content only includes content from a
publisher server 702.
Next, a second user interface can be displayed (step 706). To display the
second user
interface, a document containing a script can be requested, where the request
includes an
indicator. For example, the request can be a Uniform Resource Locator (URL)
directed to
receive a document and the indicator is an argument added to the URL. The
document can
then, for example, be received in response to the request. The script can then
be executed to
9
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
display the second user interface in response to receipt of the indicator. For
example, the
second user interface can be a browser window that is separate from a browser
window
displaying the content page.
In another implementation, the first and second user interfaces can be
displayed in the
same interface. The first and second user interfaces can be rendered by a
common browser
on a common client device. For example, the first and second user interfaces
can be rendered
in a single user interface, such as a browser window, executing on the client
device.
Subsequently, one or more content items e.g., advertisements, associated with
the
content page can be displayed in the second user interface in accordance with
the argument
added to the URL (step 708). In addition, one or more attributes for each
content item in the
second user interface can be displayed (step 710). For example, the displayed
attributes can
include a load time associated with each content item and a total load time.
In one implementation, displaying the one or more content items can be
accomplished
by utilizing a client-side implementation. For example, a copy of the one or
more content
items to be inserted into a content item slot can be received from one or more
content servers
and saved. An onload callback can then be registered for the content page.
During the
onload callback, the second user interface is displayed, and a scan is made
through the
content item slots. After making a scan through the content item slots, all of
the code, e.g.,
HTML code, associated with the content items can be combined. The combined
HTML code
can then be inserted into the second user interface and all of the content
items can be
generated.
In another implementation, displaying the one or more content items in the
second
user interface can be accomplished by utilizing a server-side implementation.
For example,
one or more content item identifications associated with one or more content
items can be
captured with JavaScript. A second user interface can then be opened, and a
request can be
made to one or more content servers for the one or more content items by
utilizing the one or
more advertisement identifications. The one or more content items received
from the one or
more content servers can then, for example, be rendered in the second user
interface. In an
implementation, a load time associated with each content item can be displayed
in the second
user interface. In an implementation, a total load time can be displayed in
the second user
interface.
In some implementations, the source code associated with the second user
interface
can be saved. For example, the user can view and save the source code of the
page in the
second user interface. Saving the source code can be useful in demonstrating
the latency of
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
one or more content items to an operator of a content server responsible for
the latency.
Specifically, the source code can be used to pinpoint which content item(s),
i.e.,
advertisement(s), produce the most delay in load time. The source code can,
for example, be
emailed directly to the operator of the content server. The source code can
then, for example,
be loaded in a user interface, such as a browser, to demonstrate the latency
with a particular
content item(s).
Another example process 800 for determining the latency time associated with
one or
more content servers, such as the second content server 142, is illustrated in
Fig. 8. After
determining the source of latency associated with a content page, a first
portion of a content
page can be loaded in a first user interface, where the first portion includes
content received
from a publisher server (step 802). For example, the first portion of content
may not include
one or more content items from one or more content servers.
Next, a second user interface can be displayed (step 804). Subsequently,
source code,
i.e., HTML code, associated with a second portion of the content page can be
displayed in the
second user interface, where the second portion includes one or more content
items received
from one or more content servers (step 806). To display the source code, e.g.,
HTML code,
associated with the one or more content items in the second user interface, a
document
containing a script can be requested, where the request includes an indicator.
For example,
the request can be a Uniform Resource Locator (URL) directed to receive a
document and the
indicator is an argument added to the URL. The document can then, for example,
be received
in response to the request. The script can then be executed to display the
second user
interface including the source code associated with the one or more content
items in response
to receipt of the indicator.
For example, the argument "google_capturenorender" can be added to the URL of
a
web page content location as follows:
http://www.webpage.com?google_capture_norender.
In response, a second user interface can be displayed that contains the source
code associated
with the one or more content items. The source code can then, for example, be
copied (step
808), pasted into an editor (step 810), and then saved to a file (step 812),
such as a local
HTML file. Thereafter a user interface, such as a browser or other user
interface, can be
utilized to open the file, e.g., the local HTML file, which contains the
source code associated
with the one or more content items (step 814). When opened, the file can
render the one or
more content items associated with the content page in the user interface
(step 816). In
addition, one or more attributes associated with the one or more content items
can be
displayed in the user interface (step 818). For example, the attributes can
include a load time
11
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
associated with each content item and a total load time associated with the
one or more
content items.
Fig. 9 is another example process 900 for determining the latency time
associated
with one or more content servers, such as the second content server 142. The
process 900
begins by loading a first portion of a content page in a first user interface,
where the first
portion includes content received from a publisher server (step 902). For
example, the
portion of the content page loaded into the first user interface may not
include content from
one or more content servers. Next, a second user interface is displayed (step
904). For
example, the second user interface can be a window, such as a pop-up window,
that is
displayed in addition to the first user interface.
A second portion of the content page can then, for example, be displayed in
the
second user interface, where the second portion includes one or more content
items received
from one or more content servers (step 906). In addition, one or more
attributes associated
with the one or more content items can be displayed in the second user
interface (step 908).
For example, the attributes can include a load time associated with each
content item and a
total load time associated with the one or more content items.
Fig. 10 is an illustration of an example second user interface 1000 as
described in the
processes above. As described, one or more attributes associated with the one
or more
content items can be displayed in the second user interface 1000. In one
implementation,
location and size information 1002 associated with each content item can be
displayed in the
second user interface 1000. In another implementation, the content item 1004
can be
displayed in the second user interface 1000. In another implementation, a load
time 1006
associated with each advertisement can be displayed in the second user
interface 1000. For
example, an individual load time 1006 can be associated with the advertisement
1004
displayed with the location and size information 1002. In another
implementation, a total
load time 1006 can be displayed in the second user interface 1000.
The apparatus, methods, flow diagrams, and structure block diagrams described
in
this patent document may be implemented in computer processing systems
including
program code comprising program instructions that are executable by the
computer
processing system. Other implementations may also be used. Additionally, the
flow
diagrams and structure block diagrams described in this patent document, which
describe
particular methods and/or corresponding acts in support of steps and
corresponding functions
in support of disclosed structural means, may also be utilized to implement
corresponding
software structures and algorithms, and equivalents thereof.
12
CA 02696481 2010-02-04
WO 2009/021138 PCT/US2008/072526
This written description sets forth the best mode of the invention and
provides
examples to describe the invention and to enable a person of ordinary skill in
the art to make
and use the invention. This written description does not limit the invention
to the precise
terms set forth. Thus, while the invention has been described in detail with
reference to the
examples set forth above, those of ordinary skill in the art may effect
alterations,
modifications and variations to the examples without departing from the scope
of the
invention.
13
