これから説明する全ての例では、ビーコンや before_beacon イベントハンドラーから出力されるデータを取得する必要があります。このページではその使い方を説明します。
たいていの場合、パフォーマンスの結果をサーバーへ送って後で解析したり参考にできるようにしたいと思います。まず最初にやることはビーコンとして使う JavaScript で URL を設定することです。詳しい内容はこの後で紹介します。BOOMR.init() メソッドの beacon_url パラメーターを通してビーコンの URL を boomerang に伝えます:
<script src="boomerang.js" type="text/javascript"></script>
<script type="text/javascript">
BOOMR.init({
beacon_url: "http://yoursite.com/path/to/beacon.gif"
});
</script>
例では beacon.gif が使用されていますが、実際は何でも構いません。同様にビーコンのハンドリングを PHP や C#、JSP などのスクリプトで書くこともできます。バックエンド上で何も起こらなかった場合はその URL を使用しバッチ処理でビーコンのパラメーターを取得するために apache のウェブログを後で調べましょう。
いくつかのパラメーターを保持してビーコンはサーバーへ送信されます。またそれぞれ独自のパラメーターを追加するプラグインも設定すれば、同様にパラメーターを取得できます。これは初期状態で取得できるものです:
name|value の形式になります。r と strict_referrer が明らかに違う場合だけ設定します。cookie の1つや、W3C Navigation Timing API のための navigation や、Google Toolbar のための古い Chrome の csi や gtb などといったものになるでしょう。
ビーコンの結果がサーバーへ送信されない可能性があるため、あなたは JavaScript 内で自分でパフォーマンスの値を調べ、このデータをもとにいくつかの判断をしたいかもしれません。before_beacon イベントを登録することによってビーコンが発生する前のデータを取得できます。
BOOMR.subscribe('before_beacon', function(o) {
// Do something with o
});
イベントハンドラーは1つのオブジェクトのパラメータと一緒に呼び出されます。このオブジェクトは上であげた v パラメーターを除く全てのビーコンのあらメーターを含んでいます。boomerang のバージョンを取得する場合は BOOMR.version を使用してください。
これ以降の全ての使用方法のドキュメントでは、before_beacon ハンドラーで以下のようなコードを使います:
BOOMR.subscribe('before_beacon', function(o) {
var html = "";
if(o.t_done) { html += "This page took " + o.t_done + "ms to load<br>"; }
if(o.bw) { html += "Your bandwidth to this server is " + parseInt(o.bw/1024) + "kbps (±" + parseInt(o.bw_err*100/o.bw) + "%)<br>"; }
if(o.lat) { html += "Your latency to this server is " + parseInt(o.lat) + "±" + o.lat_err + "ms<br>"; }
document.getElementById('results').innerHTML = html;
});
シンプルなバックエンドスクリプトはこのようになります。注意、あなたの環境外の URL パラメーターを取得するコードは含んでいないことに注意してください。使い方をすでに知っていると仮定しています。以下のコードはパラメーターは params という変数名になっていると仮定します。コードは JavaScript ですが、あなたの好きな言語で書くこともできます。
function extract_boomerang_data(params)
{
var bw_buckets = [64, 256, 1024, 8192, 30720],
bw_bucket = bw_buckets.length,
i, url, page_id, ip, ua, woeid;
// First validate your beacon, make sure all datatypes
// are correct and values within reasonable range
// We'll also want to detect fake beacons, but that's more complex
if(! validate_beacon(params)) {
return false;
}
// You may also want to do some kind of random sampling at this point
// Figure out a bandwidth bucket.
// we could get more complex and consider bw_err as well,
// but for this example I'll ignore it
for(i=0; i<bw_buckets.length; i++) {
if(params.bw <= bw_buckets[i]) {
bw_bucket = i;
break;
}
}
// Now figure out a page id from the u parameter
// Since we might have a very large number of URLs that all
// map onto a very small number (possibly 1) of distinct page types
// It's good to create page groups to simplify performance analysis.
url = canonicalize_url(params.u); // get a canonical form for the URL
page_id = get_page_id(url); // get a page id. (many->1 map?)
// At this point we can extract other information from the request
// eg, the user's IP address (good for geo location) and user agent
ip = get_user_ip(); // get user's IP from request
woeid = ip_to_woeid(ip); // convert IP to a Where on earth ID
ua = get_normalized_uastring(); // get a normalized useragent string
// Now insert the data into our database
insert_data(page_id, params.t_done, params.bw, params.bw_err, bw_bucket, params.lat, params.lat_err, ip, woeid, ua);
return true;
}
上記のコードは1日に数千のリクエストがある場合に適しています。その数が数千、数百万と増える場合、ビーコンのハンドラーはすぐにボトルネックとなります。そういった場合はビーコンを単純にバッチ処理にすることができます。リクエストは apache のログに残り、定期的にそれらのログをバッチ処理によってデータベースに挿入します。
scaling MySQL writes は MySQL を使った大きなビーコンの結果のハンドリングの仕方について IPC Berlin 2010 で話したときの資料です。いい解決方法への参考になるかもしれません。
データを取得できると、その解析した統計があると便利です。これは今後の使用方法で説明しますが、今のところ the statistics of web performance の ConFoo 2010 の資料が参考になると思います。
最新のソースコードとドキュメントは github.com/SOASTA/boomerang に公開されています。