タグ

運用に関するkuroazukiのブックマーク (2)

  • 画像配信の負荷分散も比較的簡単?(その1) - 最速配信研究会(@yamaz)

    30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ(画像とか)を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分

    画像配信の負荷分散も比較的簡単?(その1) - 最速配信研究会(@yamaz)
  • 【埋】「何でもRSS」の良し悪し - トラフィック・コントロールとRSS粒度

    日曜コラムです、こんばんは。 「あまとも」に 商品別RSS が加えられたのは、ちょうど2週間前のことです。 それまでは「あまとも」に登録されている商品全体に対して、 価格変動のあった商品をお知らせするRSSを1つだけ提供していたのですが、 自分の興味の無い商品の価格変動を延々と見せられても困りモノですので、 ユーザのみなさんが自分の興味のある商品の変動だけをRSSリーダに登録 できるように商品別RSSを吐き出すように変更してみたのです。 ところが、この商品別RSSを提供し始めてから、ある変化が起こりました。 サーバ負荷が急激に上がる時間帯が出始めたのです。 RSS自体は全て、価格が変動したときだけ更新される静的なxmlファイルで、 価格チェック処理ののときに合わせて、いわば「ついで」として吐き出す ようにしているもので、生成処理に特に負荷が掛かるワケでもありません。 では何がこんなに負荷と

    【埋】「何でもRSS」の良し悪し - トラフィック・コントロールとRSS粒度
  • 1