こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド） 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月経ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。 サイト情報 （これAnalyticsを直接貼るのはどうやればいいんだろう？） 直近一ヶ
2007年05月11日18:45 カテゴリiTech あなたのページを最速にする14の掟 人気Webサイトの管理人、必読。 紹介ページ: 14 rules for fast web pages (Skrentablog) PPTのスライド: http://www.web2expo.com/presentations/webex2007/souders_steve.ppt 実は、これらはYahoo!の"Chief Performance Yahoo!"(本当にそういう役職名)であるSteve Soudersによる以下のblog entriesをまとめたもの。 Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests Performance Research, Part 2:
mod_rewriteでサーバーの負荷が高いときだけリダイレクトする ワタシが働いている会社のホームページは、たまーにYahooのトピックスからリンクされます。 トピックスに載るとそれはもう大量のアクセスが津波のように押し寄せてきて、あっというまにサーバーのリソースを食いつぶしてアクセス不能になってしまいます。 こういうときのために、Contents Delivery Networkによるキャッシングも利用してます。 今までは、リンクされそうになったらmod_rewriteでリダイレクトって方法を使っていました。 でも毎回これをやるのが面倒になってきたので、なんとかならんかなーと思って、RewriteMapに初挑戦してみた。 RewriteMap使えばRewriteCondとかRewriteRuleにプログラムの出力結果を使うことが出来るようになるので、これでWebサーバーのロードアベレー
http://d.hatena.ne.jp/yamaz/20060509の続き. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. Googleはimages.google.com 1つで1,187,630,000(11.8億!)の画像を保持している(ように見える).1つの画像が10KBだったとしても12.5TBの画像を保持していることになる. GoogleがこんなことができてるのはGoogleFileSystemがあるからだ. http://labs.google.com/papers/gfs.html GoogleFileSystemは簡単に言うとデータバックアップ機能つきの分散NFSのようなものだ. GoogleFileSystemに関しては上記URLのPDFに詳しいので,そちらを参照してほしいが,基本的な考え方は今まで負荷分散の考え方となんら変ることはない.つまり
画像配信の負荷分散も比較的簡単？（その2）のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. アクセス/保持データ量ともに多くなってきてどうにもならなくなったらどうするか?お金があるところはサーバを強化したりメモリを増やしたりするのも手だろう.ただもっと安上がりで効果的な方法がある. どうにかなるまで1台あたりのアクセス数と保持データ量を減らせばいいのだ. ずっこけた人がいるかもしれないけど,こっちは大真面目である(笑).別にアクセスが少なくなるまでサービスを縮小させろという意味ではないので,もうちょっと付き合っていただきたい. 下記のような仮想の実装例を考えてみよう. http://i.yimg.jp/images/search/head_050825.gif にアクセスがあったらURLを10で割ってその余りに応じて img0.yimg.jp img1.yim
http://d.hatena.ne.jp/yamaz/20060426 の続き.待ち行列理論に従うと遅延のないサービスを行うためには サーバの単位時間のリクエスト処理能力 > ユーザの単位時間のリクエスト数 という非常に単純なことを行えばいいことになる.「なにをあたりまえのことを...」と思われるかもしれないがもうちょっと付き合っていただきたい. ところでたいていのBlogや画像サービスのサービスURLはこうなってる. http://ホスト名/<ユーザ名>/ http://ホスト名/id?ユーザ名 http://ホスト名/ディレクトリ名/コンテンツ名 例で言うと下記のような感じだ. http://d.hatena.ne.jp/yamaz/ http://mixi.jp/show_friend.pl?id=128497 http://i.yimg.jp/images/search/head
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く