This repository has been archived by the owner on Apr 15, 2019. It is now read-only.
/
methodology.html
144 lines (137 loc) · 5.35 KB
/
methodology.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
<!DOCTYPE HTML>
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8">
<title>Boomerang methodology</title>
<link rel="stylesheet" type="text/css" href="boomerang-docs.css">
</head>
<body>
<span style="float:right;"><a href="./">All Docs</a></span>
<h1>So how does this thing work?</h1>
<h2>1. Roundtrip measurements</h2>
<p>
We define round trip time as the time taken from the user initiating a resource request
to when that resource is completely available for the user to interact with. We limit
our measurements only to HTML page type resources and only to resources requested by a
click or link activation on a page that we control.
</p>
<p>
The round trip time is therefore the time from the user clicking on a link to the page
referenced by that link becoming usable by the user. For most cases, this is as good
as measuring the time from the previous page's onbeforeunload event firing to the current
page's onload event firing. In some cases this may be different, but we let the
developer determine those events.
</p>
<p>
This is how we measure.
</p>
<ul>
<li>
<p>
attach a function to the <code>window.onbeforeunload</code> event.
</p>
<p>
Inside this function, we take a time reading (in milliseconds) and store it into a
session cookie along with the URL of the current page.
</p>
</li>
<li>
<p>
attach a function to the <code>window.onload</code> event.
</p>
<p>
Inside this function, we take a time reading (in milliseconds). Then we look for
the cookie that was set in the onbeforeunload handler of the previous page. If we don't
find a cookie, we check to see if the browser has implemented the
<a href="http://dev.w3.org/2006/webapi/WebTiming/">WebTiming</a> API. If so, we
use data from there instead. If we find neither, we abort <a href="#fn-1" class="fn">[1]</a>.
</p>
<p>
If we find a cookie, we check the URL stored in the cookie with the <code>document.referrer</code>
of the current document. If these two differ, it means that the user possibly
visited a third party page in between the two pages from our site and the measurement
is invalid, so we abort <a href="#fn-2" class="fn">[2]</a>.
</p>
<p>
If we're still going, we pull the time out of the cookie and remove the cookie. We
measure the difference in the two times and this is the round trip time for the page.
</p>
</li>
</ul>
<h2>2. Bandwidth & Latency measurements</h2>
<p>
Bandwidth and latency are measured by downloading fixed size images from a server
and measuring the time it took to download them. We run it in the following order:
</p>
<ul>
<li>
<p>
First download a 32 byte gif 10 times serially. This is used to measure latency
</p>
<p>
We discard the first measurement because that pays the price for the TCP handshake
(3 packets) and TCP slow-start (4 more packets). All other image requests take
two TCP packets (one for the request and one for the response). This gives us a
good idea of how much time it takes to make an HTTP request from the browser to
our server.
</p>
<p>
Once done, we calculate the arithmetic mean, standard deviation and standard error
at 95% confidence for the 9 download times that we have. This is the latency number
that we beacon back to our server.
</p>
</li>
<li>
<p>
Next download images of increasing size until one of the times out
</p>
<p>
We choose image sizes so that we can narrow down on a bandwidth range as soon as
possible. See the code comments in <a href="../boomerang.js">boomerang.js</a> for
full details.
</p>
<p>
Image timeouts are set at between 1.2 and 1.5seconds. If an image times out, we
stop downloading larger images, and retry the largest image 4 more times<a href="#fn-3" class="fn">[3]</a>.
We then calculate the bandwidth for the largest 3 images that we downloaded. This
should result in 7 readings unless the test timed out before that <a href="#fn-4" class="fn">[4]</a>.
We calculate the median, standard deviation and standard error from these values
and this is the bandwidth that we beacon back to our server.
</p>
</li>
</ul>
<p class="perma-link">
The latest code and docs is available on <a href="http://github.com/yahoo/boomerang/">github.com/yahoo/boomerang</a>
</p>
<div id="footnotes">
<h2>Footnotes:</h2>
<ol>
<li id="fn-1">
We don't actually abort at this point, but give the developer the ability to
salvage the moment by setting his/her own start time. This is most useful when the
developer isn't measuring full page load time, but possibly the load time of some
dynamic content loaded via Javascript.
</li>
<li id="fn-2">
We offer the developer the ability to not abort at this point, but instead
pass all URLs to the back end and let the server decide whether to discard the
beacon or not. This is useful for sites that have a login page behind SSL and
possibly redirect to the login page if the user clicks on certain links. In this
case there might either be no referrer, or the referrer may not match.
</li>
<li id="fn-3">
This value is configured using the <code>BW.nruns</code> parameter. See
<a href="howtos/howto-6.html">Howto #6</a> for details on configuring boomerang.
</li>
<li id="fn-4">
The bandwidth test times out after 15seconds. At that point it will try to
determine the bandwidth based on data that it has already collected.
</li>
</ol>
</div>
</body>
</html>
<!--
Copyright (c) 2011, Yahoo! Inc. All rights reserved.
Copyrights licensed under the BSD License. See the accompanying LICENSE file for terms.
-->