負荷対策のためロボット向けページ表示時のDBアクセスを省略する


最近 サーバ負荷 がかなりマズイことになっています。
今度こそ間違いなく、回線負荷ではなくサーバのCPU負荷です。
 
Load Averageの値が昨年10月頃には 平均2.5 くらいだったものが、
現在では 5.0くらいまで膨らんで きています。既にレッドゾーンです。
皆さまにはご迷惑をお掛けして誠に申し訳ございません。
 
 
急いで対策を考えなければいけないのですが、その中で
以前から気になっていたことを1つ試してみることにしました。
それは検索エンジンの 巡回ロボットの負荷対策 です。
 
現在のあまともやコミックダッシュ!は、トップページや
ランキングのページなどは負荷対策のため最初から 静的HTMLのページ
になっています。しかし、そのほかのページ、たとえばシリーズ情報の
ページや、各ユーザの蔵書一覧のページなどは 全て動的生成 です。
 
これは何を意味するのかといいますと、アクセスしてくる人がたとえ
巡回ロボットであったとしても、純粋なユーザのアクセスと同じように
 
 その場で ”DBから” 最新情報を引き出して
 
出力HTMLを一所懸命作り上げることになります。
 
これが少量のアクセスなら良いのですが、あまともやコミックダッシュ! のように
商品数やユーザ数によってページ数がどんどん増えていく
タイプのサービスだと、巡回ロボットのアクセスのほうが
一般のユーザのアクセスより格段に多くなります。
 
具体的には 約9割がこうした巡回ロボットのアクセスなのです。
 
 
そこでこんな仕組みを考えました。
 
巡回ロボットがアクセスに来たときに、そのページの内容を
丸々キャッシュとして ファイルに落としておき、次回ロボットが
同じページをクロールしてきたときには、10日以内であれば
キャッシュの内容をそのまま読み込んで返す、というものです。
 
CGIがUserAgentを判別して、巡回ロボットのときだけこうした動作をします。
一般のユーザ向けにはキャッシュは使わず、常に最新の情報が返ります。
CGI自体の起動は避けられませんが、毎回毎回ページ情報の構成のために
大量にDBにアクセスしていたぶん の負荷はこれで大幅に軽減されるはず、です。
 
ちなみにGooglebotは私のサイトのページを合計で 3万ページ/日 も拾っていきます。
平均して 2~3秒に1回 のペースが24時間休みなく続いているようなイメージです。
これらに それぞれ×数回以上のDBアクセス が伴っていると考えるとゾッとします。
 
今回作ったキャッシュは別々のロボットの間でも同じものを使いまわしますので、
Googlebot、Yahoo! Slurp、msnbotなど 多種多様なロボット が同じページに
アクセスしてきても、キャッシュの生成は全部あわせて10日に1度で済みます。
 
本来、UserAgentによって別の情報を返すことは対検索エンジンのマナーからいうと
良くないのですが、情報をフェイクしているワケでもありませんし、サーバ負荷が
危機的状況に陥っていることも鑑みると酌量の余地はあると思っています。
 
仕組みの性質上、最初のうちはキャッシュの 「生成」 の率が高く、
逆に負荷を上げてしまう可能性がありますが、時間が経つにつれて
キャッシュの 「流用」 の率が上がってくる見込みになります。
 
すでにこの試みを始めて3日目になりました。初日=3%、2日目=6%、3日目=12%
と順調にキャッシュ利用率が上がっているのが確認できています。
サーバ負荷にもほんの僅かながら改善の傾向が見られました。
このままキャッシュ利用率が5割を超えるくらいまで育ってくれることを願っています。


2008/05/06 [updated : 2008/05/06 23:59]


この記事を書いたのは・・・。
CK@デジモノに埋もれる日々 @ckom
ブログ「デジモノに埋もれる日々」「アニメレーダー」「コミックダッシュ!」管理人。デジモノ、アニメ、ゲーム等の雑多な情報をツイートします。




« はてなポイントによる「投げ銭」を延々と投げ続る意味と効果

トップに戻る

SH903iのバッテリをドコモショップで交換 - 結果的に無償でした »


▼ はてなブックマークのコメント ▼

leva 2008/05/09
クロール対象が大規模になるサービスでは、ボット向けには人間よりキャッシュを多用した方がよいということ
nshash 2008/05/09
クロール対象が大規模になるサービスでは、ボット向けには人間よりキャッシュを多用した方がよいということ
はてなブックマークで
コメントしましょう


「Kindle本対応」に「スマホ完全対応」! コミックダッシュ!数年ぶりの大規模アップデートです。


「アニメスタイル005」は明日4/30発売、コミックダッシュ!の広告も載ってますw


「アニメスタイル005」に「コミックダッシュ!」のモノクロ広告を出させて頂く予定です


メガとんトラックのスマホページにページ処理を追加、コミックダッシュ!の新刊カレンダーも


コミックダッシュ!が重複商品だらけ、原因は「Kindle版」の出現


コミックダッシュ!に画像検索リンク追加 - 気になるシリーズの雰囲気をチェック


コミックダッシュ!他、サービス一時不具合のお詫び(7/16 am 4:14~11:44)


「ヒャッコ」「にゃんこい!」Flex Comixの出版元は全てソフトバンクからほるぷ出版へ


「あのマンガは○年世代?!」 過去10年(2002~2011)の新刊シリーズランキングを作ってみた


マンガ読みならおさえておきたい! 2011年初刊のコミックシリーズ・ランキング


Amazonからブックマークレットでコミックダッシュ!に飛ぶ(スマホ編)


Amazonからブックマークレットで直接コミックダッシュ!のページに飛ぶ方法

ピックアップタグ




ブログ内検索



▼ コメント ▼

No.18867   投稿者 : きりけん   2008年5月11日 03:44

Linuxでcpu負荷がLoadAverageを押し上げる要因になることはほとんどありません。
大抵の場合、ボトルネックは別の理由だったりします。
メモリ不足で大量のswapアクセスが発生するとか(RDBMS+Apacheはご存知かとは思いますが、激しくメモリを消費します)ミドルウェアの設定チューニング不足とか(大抵の場合デフォルトではサーバリソースを占有しないように設計されていますが、組み合わせて使うとそれがかえって仇になることもあります)
メモリ増量やRDBMS設定パラメータの見直しでも効果があるかと。
UserAgentによって別の情報を返すのは最終手段ではないでしょうか?


No.21633   投稿者 : annkokunokizinn   2008年7月16日 10:25

ロボットのアクセスの数が自分のサイトブログ
のほうにはたくさん歩けどホムペのほうには逆にロボットが少ない状況
どうやらサーバーによってもホムペよりブログのほうが高待遇であるようだ


ご自由にコメントください(=゜ω゜)ノ
※管理人は多忙のためお返事はほとんどできません(スミマセン)。
スパムおよび本文と無関係なコメントは削除対象になる可能性があります。


保存しますか?




★コミックダッシュ! 10,000人突破ありがとうキャンペーン!(9/18~10/23)
 
デジモノに埋もれる日々 : (C) CKWorks