競技ルール#
競技内容#
みなさんには,実装Aをさらに改良して実装Cの速度を上回るような高速化を行ってもらいます. 各グループが作成したwebシステムの性能はベンチマークサーバによって計測されます. ベンチマークのランキングはリアルタイムに確認可能ですので,1位を目指して頑張ってください.
検索サーバ高性能化コンテストの独自仕様#
各班の出力形式による速度の違いを回避するために,以下のJSON形式で出力するようにしてください.
Content-Type:application/json
リクエストの全体
キー |
タイプ |
説明 |
---|---|---|
tag |
string |
タグ名 |
results |
[]TagResult |
そのタグが含まれるレコードの一覧で撮影時刻降順(最新順).ただし,撮影時刻が同じレコードの順序は問いません.また,100件を超える場合は上位100件のみを返してください. |
TagResult
キー |
タイプ |
説明 |
---|---|---|
lat |
float |
緯度 |
lon |
float |
経度 |
date |
string( |
撮影時刻 |
url |
string( |
写真のURL |
例
{
"tag": "flamingofilter",
"results": [
{
"lat": 37.616333,
"lon": -77.527664,
"date": "2012-08-01 11:11:04",
"url": "https://farm9.static.flickr.com/8226/8569131977_60823a1a25.jpg"
},
{
"lat": 43.922165,
"lon": 4.786333,
"date": "2012-07-09 19:02:43",
"url": "https://farm9.static.flickr.com/8107/8484932516_ca2fa47cf0.jpg"
},
{
"lat": 44.192333,
"lon": 4.741333,
"date": "2012-07-09 19:00:57",
"url": "https://farm9.static.flickr.com/8384/8483835779_d9a8eccde2.jpg"
}
]
}
採点方法#
webシステムの性能値(スコア)の高さを競うものとします.
webシステムの性能値は,webシステムのRequest Per Second(1秒間に処理を行うHTTPリクエストの数)で評価し,このスコアが1番高いチームを優勝とします.
競技日程#
本競技は予選期間・本選期間からなります.各期間は講義スケジュールのページを確認してください.
予選と本選でのベンチマークサーバの違い#
予選用と本選ではベンチマークサーバの仕様が若干異なります. 以下に予選と本戦での違いを記載します.
計測回数:予選用ベンチマークサーバに計測を要求できる回数に上限はありません.本選用ベンチマークサーバに対して計測を要求できる回数は各グループ最大10回とします.
タグ:予選では計測に使用されるタグに条件はありません.本選ではグループ内の異なる計測で同じタグは使用されません(異なるグループ間の計測で同じタグが使用されることはあります).
禁止事項#
本選において,計測に使用されるタグを推測するために複数のグループで協力する行為を禁止します.
ベンチマークサーバを悪用して他グループや学内・学外のシステムに対してリクエストを送る行為を禁止します.
ベンチマークサーバに直接アクセスを試みる行為を禁止します.
ベンチマークサーバにループなどを使用して大量の計測リクエストを送信する行為を禁止します.
ヒント#
検索システムにはキャッシュが存在します.このためMySQLなどでは同じ検索ワードで複数回検索を行うと2回目以降で検索速度が早くなることがあります.(特に本選用ベンチマークサーバは)限られた回数しかベンチマークを実行できず,実行ごとの検索ワードも異なります.このため,特定の検索ワードのみ検索を早くしたり,単純な方法でキャッシュによる高速化を行うことは難しくなっています.どのような単語で検索されても(それが過去に問い合わせされたことがない検索語でも)高速に返答をするためにはどのような方法があるかを考えてみましょう.
また,イメージを掴みやすくなるよう,いつくかの言語でサンプルプログラムを用意しました.HTTPリクエスト・レスポンスの確認など参考にしてみてください. ただし,高速化は一切行われていません.これをベースとして高速化を行うのも良いですし,全く新しいものを開発していて頂いても構いません.