Hatena::ブログ(Diary)

28.8kbps

March 13(Sat), 2010

ニコニコ動画のユーザー名からIDとマイページを検索するWebサービスを作った

| 00:26 | ニコニコ動画のユーザー名からIDとマイページを検索するWebサービスを作ったを含むブックマーク

ニコニコユーザー検索

http://nolze-labs.appspot.com/nico2usersearch/

本プロジェクトから逸れました。Google App Engine for Pythonで動いてます。総制作時間二日。制作理由は、ユーザー名からマイページを逆引する用があったからです。まんまです。いやらしい用ですね。超試作段階。独自クローラーが毎分3リクエスト今4リクエストにしてみました、でクロールしてます。

クローラーBigTableにIDとURLとユーザー名を格納しているのですが、URLはいらない気がします。したのでやめました。検索部で合成してます。

App Engineでは一日当たり65万7000回のコールが可能で、現在のニコニコ動画総ユーザー数は200万人くらいです。よって理論上は4日で読み切れるはずなのですが、セッション時間の兼ね合いもあり、今の段階では一日6000コール程度に留まっています。今後安定具合を見て増やす予定したい。(※追記参照)

Todo:

  • 外部CSSが読み込めていない
  • デザイン改善
  • クロール間隔の調整

取り急ぎ。

March 13(Sun), 2010追記

  • 何故か13:30頃一瞬アクセスが跳ね上がった。謎。
クロールについて

クローラが行う操作は基本的にurlfetch・BigTable読み・BigTable書きの3操作で、先述のようにurlfetchはAPI一日65万7000コール、毎分3000コールが無料割り当てになっています。BigTableにも割り当て制限はあるのですが、API1000万コールというとんでもない余裕っぷりなので気にしてません。今のところ一日の割り当てを一番食っているのはデプロイ回数の10%ですw 次がCPU Timeの4%.

問題は2点あって、ひとつはセッション時間の制限。Error 404 (Not Found)!!1にさりげなく書いてあるのですが、

リクエスト ハンドラがリクエストを処理し、レスポンスを返す時間には、制限が設定されています(一般的には 30 秒前後)。制限時間を過ぎると、リクエスト ハンドラは割り込まれます。

ということで一回のクロールで20程度が限界だと思われます。

そしてこれに絡んでもうひとつの問題、相手サーバーの負荷ニコニコ動画のシステム内なら一瞬にして手に入るデータをあくせく集めているだけなので、相手側にしてみれば割と無駄な負荷の部類だと考えています。そこで、当然のマナーといえば当然なのですが、今のクローラには一回のフェッチ毎にsleepを挟んで遠慮させています。この都合もあって、実際の取得数は1クロールあたり3, 4件がせいぜいというところ(実測で)。cronはevery 1 minutesで掛けてますが、それでも多くて4*60*24=5760コールと割り当ての1%さえ生かせていません。ここをなんとかしたい。

検索実装について

完全一致検索にしてます。できたらフレキシブルにしたいけどこれはこのままでも良い気がする。

BigTable拭きについて

クロール再開時にBigTableから最大IDを読んでいるのですが、節操なくつぎ込んでいるので番号がたまるたまる。なんか勿体ないので1日1回くらいリセットするのを書こうと思う。書いた。定期的に最大値以外のエンティティを削除しています。

目標

これを深追いする予定はないので、クローラ最適化して、デザイン整えて、時々メンテくらい。

トラックバック - http://d.hatena.ne.jp/nolze/20100313/1268493994