2010-07-09
図書館クロール補足
|なんか技術的におかしなことを言っている人がいたら追記していくかも知れません。
クロール頻度が妥当かどうかの話
ウェブサーバーはマルチスレッド、マルチプロセスなどで複数のリクエストを同時に処理できるようになっているのが一般的であるため「前回のリクエストが完了してから、次のリクエストを投げる」実装になっている限りは「サーバーの性能を100%使いきって他の利用者が利用できない状態」になることは、通常起きません。
例外的なケースもあります。
- ウェブサーバーがリクエスト完了後に何らかの処理を行うような実装になっていて、リクエストのペースによっては処理が溜まっていって追いつかなくなる。
- ロードバランサ、リバースプロキシを使ったフロントエンド/バックエンドの構成になっているサーバーで、フロントエンドがタイムアウトと判断して早々にエラーを返したが実際はバックエンドで処理が続いている。
例えば1秒で処理が終わらないページ(例:LIKE検索)に対して、レスポンスの受信を待たずに1秒に1回のペースでリクエストを投げ続けたら、サービス停止を引き起こせるでしょう。ですが、並列してリクエストを投げていないのに「お前のリクエストが原因で他の利用者が利用できない状態になった」という主旨のことを言われたのであれば、それは通常言いがかりです。他の利用者のリクエストと合わせて過負荷状態になっている(一人の責任にされるべきものではない)か、アプリケーションのバグが原因の事故であると考えるのが自然です。
「サーバーリソースが限られているので遠慮してくれ」というのは、別段おかしなことではありません。が、サービス停止の責任を追求されるのは異常なことです。
1秒1回のペースが妥当かどうかとか、どの程度のウェイトを入れるべきなのかという話は、クロール対象のサービスの規模や、静的ページか動的ページかなどによっても変わるでしょう。もし書いたプログラムを配布する場合は、複数の利用者によってリクエストが同時に投げられることになるので、慎重さが要求されるでしょう。
開発中で自分の手元でしか動いていない相手先のサーバーに並列アクセスしないクローラが原因でサービスが落ちて他の利用者が迷惑しているといって責任を追求されるというのは、技術的におかしいことを言われているのです。それは予見できない事故です。並列アクセスしてないのにサーバーが落ちるのであれば、それはサーバー側のバグが原因である可能性が高い(実際そういう考察をしている人が何人かいますね)。
という程度のことを警察が判断できるようになると良いですね。
- 47 http://twitter.com/
- 35 http://b.hatena.ne.jp/
- 25 http://reader.livedoor.com/reader/
- 23 http://b.hatena.ne.jp/entrylist
- 22 http://b.hatena.ne.jp/hotentry
- 10 http://d.hatena.ne.jp/
- 10 http://phpspot.org/blog/archives/2010/07/201078.html
- 8 http://hootsuite.com/dashboard
- 7 http://twitter.com/bulkneets
- 6 http://b.hatena.ne.jp/entrylist?url=http://d.hatena.ne.jp/mala/
- 2010-07-07 射撃しつつ前転 5/91 5%