ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
JavaScriptのsetTimeoutについて - 最速配信研究会(@yamaz)
JavaScript を学ぶ際に一番重要なのに、誤解されがちな setTimeout 系の概念 http://d.hatena.ne.jp/amachang/20060910/1157911122 上記はてブコメント http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/amachang/20060910/1157911122 JavaScriptがシングルスレッドなのは仕様？ http://d.hatena.ne.jp/ajiyoshi/20060911 でsetTimeoutの仕様について熱く語られている.私も興味を持ったのでざっと調べてみた. まず超基本的な話としてマルチプロセスなOSにおいて完璧な 時間制御というものは無理ということだ.これは話を極端にして ｢1万個ブラウザ立ち上げてきっちり1msecごとになにかをさせようとしたらちゃん
ひよったところからほころびはじめる - 最速配信研究会(@yamaz)
POBoxなどのUIの神,増井さんが提唱してる「富豪的プログラミング」という考え方がある. http://pitecan.com/fugo.html ざっくり言うと「今の世の中マシンパワーとかあまりまくってるからヘタにチューニングしたりメモリや実行効率なんかは考えずにガンガン行こうぜ!」というお大尽な方法だ. 増井さん的にはUIに特化した話のつもりだと思うんだが,どうも一般のシステムにも上記思想を持ち込んでるケースが多々見られる. まぁ.マシンパワーはモリモリ増えてるので,それでもいいんだろうけど,富豪すぎるのもどうよ？と日々感じてたところ下記のエントリがあった. 平民的プログラミングのススメ http://www.oiwa.jp/~yutaka/tdiary/20051229.html#p02 > しかし、個人的に最近気になってることとしては、一方で > やたらと富豪的プログラミングが度
みなさんさようなら ---1台で同時50万接続のWebサーバーが登場 - 最速配信研究会(@yamaz)
「もう負荷分散は必要ない」---1台で同時50万接続のWebサーバーが登場 http://itpro.nikkeibp.co.jp/article/NEWS/20060707/242757/ ここまで徹底した製品が出るとはある意味いい時代といえる. こんな製品が出てしまったからにはこんな場末のBlogで 配信技術についてグダグダ話す必要もないだろう. 短い間でしたがみなさんどうもでした. ということには当然ならない.たいていのサービスはこれ1台で全部 まかなえるだろう.ただその代償としてロバストネス(堅牢性)を失う可能性があるからだ. 今までサーバ30台でまかなっていたのがこの製品1台に置き換わったとしよう. そうするとこの1台が落ちたとき＝サービス停止となる.これはうまくないだろう. 「じゃあ2台買えばいいじゃん.」 という意見もあるだろう.そうすると1台落ちたときにもう1台にかかる負荷
画像配信の負荷分散も比較的簡単？（その3） - 最速配信研究会(@yamaz)
画像配信の負荷分散も比較的簡単？（その2）のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. アクセス/保持データ量ともに多くなってきてどうにもならなくなったらどうするか?お金があるところはサーバを強化したりメモリを増やしたりするのも手だろう.ただもっと安上がりで効果的な方法がある. どうにかなるまで1台あたりのアクセス数と保持データ量を減らせばいいのだ. ずっこけた人がいるかもしれないけど,こっちは大真面目である(笑).別にアクセスが少なくなるまでサービスを縮小させろという意味ではないので,もうちょっと付き合っていただきたい. 下記のような仮想の実装例を考えてみよう. http://i.yimg.jp/images/search/head_050825.gif にアクセスがあったらURLを10で割ってその余りに応じて img0.yimg.jp img1.yim
画像配信の負荷分散も比較的簡単？（その2） - 最速配信研究会(@yamaz)
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
画像配信の負荷分散も比較的簡単？（その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 な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
画像配信の負荷分散も比較的簡単？（その4） - 最速配信研究会(@yamaz)
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に詳しいので,そちらを参照してほしいが,基本的な考え方は今まで負荷分散の考え方となんら変ることはない.つまり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
