2chに学ぶCGMとDBMSとの相性(データのローカリティはとても重要) - 最速配信研究会(@yamaz)
もう一ヶ月以上前の記事だけど,ニコニコ動画が1000万コメントを達成したというニュースがあった. 「24日で1千万コメント突破！ 「ニコニコ動画」が好調」 ドワンゴグループの1社で、メールポータルなどの事業を企画運営しているニワンゴは8日、同社がサービスを提供している「ニコニコ動画」（ベータバージョン）に投稿されたコメント数が、 オープンから24日で1,000万件を突破したことを発表した。また、1日のページビュー数が2,000万を突破していることもあわせて発表した。 http://www.rbbtoday.com/news/20070208/38344.html ニコニコ動画のすごいところは動画キャプション部は システム的に掲示板とほとんど同じで,おそらくその場に リアルでいる人の数はせいぜい数十人とかなのに,さも数100人 とかがその場にいるような臨場感を与えているところだと思う. モバ
最速配信研究会 - Web2.0とC10Kに関する数々の誤解
Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに
イベントドリブン型静的生成ブログツールの提案(その2) - 最速配信研究会(@yamaz)
イベントドリブン型静的生成ブログツールの提案 で結構な数のツッコミをいただいた(ありがとうございます). 大体の意見をまとめると. 「そんなのとっくにあるよ.」 というものであった.全部を調べたわけではないが,WordPressとHNSとMTのキャッシュシステムのソースを調べてみるとキャッシュ削除の実装としては下記のような感じだった. 毎回DBにアクセスしてキャッシュファイルとlastmodifiedの比較を行う(MT,HNS). Blogレコードのセーブ時のコールバックでキャッシュファイルを消す(WP?). 1だとWebサーバが複数台でDBが1台だとアクセスがDBに集中 しちゃうので,あまり好みではない (DBの負荷に関してはリプリケーションを作ればいいという 意見もあるだろうが,不慮の時に備えてできればサーバは いきなり投入したい). で、もっと手軽にできないものかとmod_proxy
Flashでグラフ(XML/SWF Charts)
# あおり気味のタイトルに変更:D Gigazine: Flashできれいなパイチャートや円グラフを無料で作る「amCharts」 これよりカッチョイイやつを昔ぴろさんから教えてもらったのでご紹介. XML/SWF Charts http://www.maani.us/xml_charts/index.php SwfにXMLの形でデータを渡すことで,多彩なグラフを書くことができる. ギャラリーは↓.パイチャート,円グラフ,棒グラフなどの各種グラフはもちろん,モーションつきのグラフとかも作れる(ギャラリーの各をクリックするとXMLのコードが見られます). http://www.maani.us/xml_charts/index.php?menu=Gallery ライセンスはこのあたり http://www.maani.us/xml_charts/index.php?menu=License
日本人は一人暮らしする前に「ナニワ金融道」を読むべき - 最速配信研究会(@yamaz)
UIEvolutionの中島さんがMLM(マルチレベルマーケティングの略)に引っかかった若者と話したようだ. 私が「ねずみ講って何か知ってる？」と尋ねると、「聞いたこともない」という（学校ではいったい何を教育しているのだろう）。 非常に同感で,思うところがあるので書いてみる. ずっと前にmixiで書いた奴だけど,加筆しての転載です. - mixiのとあるコミュニティでトピックが立った. 「文字入力で稼ぎませんか？」(当該トピックは消えてしまったのでちょっとあやふや). まぁよくある在宅ビジネスの勧誘だ.mixiは招待制なので, こういう悪いことはやりにくいはずなのにと思ってトピ主を たどってみるとなんと18歳の女子大生！ プロフィールを信じるならベンチャー気質の高い超有名私立大学の 新入生の女の子で,参加しているコミュニティを見ると 「ネットワークビジネス」 「ビッグになりたい」 「金持ち
最速配信研究会 - ベンチャーを志向するということ
仙石浩明の日記:ソフトウェア産業の究極の振興策 http://blog.gcd.org/archives/50816826.html ここがスタートになっていろいろ意見が出ている. スラッシュドット:日本のソフトウェア産業を振興させたいなら大企業を一つ潰せ http://slashdot.jp/article.pl?sid=06/12/11/0311248&threshold=-1 雑種路線で行こう:ベンチャーに人材が足りないのは確かだが http://d.hatena.ne.jp/mkusunok/20061212 でyamaz的にもいろいろ思うところがあるので,書いてみる.なおid:yamazの経歴は下記の通り, 田舎大学の情報系修士を修了. 外資系有名半導体メーカで1年半ほど勤務 外資系超有名ポータルで7年ほど勤務. 現在無職.立場的にはおおむねニート. この売り手優位の地合いでも，
イベントドリブン型静的生成ブログツールの提案 - 最速配信研究会(@yamaz)
動的生成のブログツールの魅力 ARTIFACT ―人工事実― 静的生成のブログツールの魅力 絵文録ことのは Blogツールのコンテンツ生成はどうするのがいいのか話されている.詳しくは上記リンクを 参照してもらいたいが,おおざっぱに問題を整理すると下記のような感じ. 動的生成 → 変更に強いが常にDB参照なのでサーバの負荷がかかる. 静的生成 → サーバ負荷はちょろいが全データの再ジェネレートに時間かかる. 結論: 一長一短だからまぁ用途によって使い分けるのがいいのかもね. たまたま似たような問題にぶつかっていろいろ考えていたところなので,私が行おうとしてる解決方法を紹介したい.考え漏れとかあるかもしれないので,ツッコミ大歓迎です. 本ブログの立場からはDBとくにMySQLやPostgreSQLのような重量級のDBMSから直接データをひくという解決はあり得ない*1.かといってデザインを変更す
selectよりkqueue,epoll(apache2のススメ) - 最速配信研究会(@yamaz)
最近3人ほどのエンジニアと話したのだがapache2に対して割とネガティブな意見を持っていた. 曰く「既存モジュールが使えないから」 曰く「スレッドベースってちょっと。。」 曰く「WEBでいい話聞かないから」 3人しか話してないんだけど,3人とも「apache2はスレッドでしか動かない」と思いこんでたようでちょっとおどろいた.apache2でも StartServers 5 MinSpareServers 5 MaxSpareServers 64 MaxClients 100 MaxRequestsPerChild 10000 という設定をすることで今までどおりpreforkモデルで動かすことはできる.preforkモデルだと各種ハンドラもスレッドセーフに無理にすることはないので,わかってて使う分には問題ない. 私がapache2を勧める1番の理由はapache2ではリクエストの多重化処理
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ごとになにかをさせようとしたらちゃん
「コネクションプーリング都市伝説」はほんとに都市伝説?（その1) - 最速配信研究会(@yamaz)
「コネクションプーリング都市伝説」という単語がある.かいつまんでいうと 「コネクションプールって一般的に速いと言われているけど,クライアントが 多くなると接続維持のコストが大きくなるから今となっては速くないんじゃね?」 というものだ. WEB+DB PRESS vol.33でnipotanさんの中の人が書いてた記事が発端だと思われる. あとこんなエントリもあった. hori-uchi.com コネクションプーリング都市伝説は正しそう またちょっと古いねたですが、WEB+DB PRESS vol.33でnipotanさんが書いてたコネクションプーリング都市伝説を読んだ時、ほんとのところどっちが速いのかってのをabでベンチマークをとってみました。 (snip) これ以外にもいくつかパスを替えてベンチマークをとったところ、いずれも若干ですがプーリングしないほうが早かったので、現在はプーリングしな
DSASの中の人の手の内情報が超すごい件 - 最速配信研究会(@yamaz)
DSAS開発者の部屋:いかにして冗長構成を作るか 〜DSASの場合〜 でDSASの中の人が手の内を公開されている.丁寧な書き口調とは裏腹に,ある種の執念すら感じとれる内容なので,皆さんぜひ読むといいです.細かい内容に関しては今後のエントリに期待するとして,「ここまでやるか？」というくらい徹底してるのでデータセンターが吹き飛ばない限りはこれで大丈夫だと思われます. 少し話がそれるが,こういう自動化に関しては徹底的にやったほうがいいと思う. 私のBlogを読んでいる人たちはおそらくは20代から30代くらいのまさに担当者レベルの方々で, 「いや勇気と根性で何とかしてますから」 という向きも多いだろう.しかしマシンの台数,負荷ともに増える一方なので,いずれ根性ではなんともならなくなる.非常に言うのはつらい話だが,実際力尽きて会社を辞めたり,彼女に振られたりした人*1を何人も見てきた私としては上記エ
最速配信研究会 - ロードバランサの運用.DSRって知ってますか
id:hirose31くんがロードバランサについてあれこれ書いてる. そんなわきゃない＞DNS RRはロードバランサの座を奪い返せるか この間彼から教えてもらったんだけどLVS(LinuxVirtualServer)は結構すごいという話. 「でも安定性がぁ」とか「ASICには勝てないよね」といかいうやつは、まずは試してみてみー きっとびっくりするから。 ロードバランサの1運用形態であるDSR(Direct Server Return)を知らない人だと「ソフトウェアでロードバランサ?ありえねー」とか思っててもしかたないと思う.DSRを知らないといつまでもベンダーに高いお金を払うことになるのでチョロチョロ書いてみる. DSRを知らない人がロードバランサーに持っているイメージは図の1の通りだと思う.つまり HUBを通してリクエストがロードバランサに届く(1,2) ロードバランサは適当にバランシン
WindowsXPのノートPCをルータにする方法 - 最速配信研究会(@yamaz)
WindowsXPには複数のネットワークアダプタを束ねるブリッジ機能がついている.これを利用して自分のノートPCをルータにする方法がある. こんなケースのときに役立つだろう. 1. FreeSpotなどで契約をしていないほかのPCもネットワークに参加させたい 2. 出先のネットワークでIPを1つもらったんだけど,それとは別にローカルLANを作ってプリンタやファイルサーバなどを共有したい. 3. カンファレンスとかで無線LANが使用できたんだけど,みんなが接続しすぎててIPが取得できない. やり方は下記のとおり 今回作りたい構成 WAN <-> 無線LAN(NotePC) <-> ブリッジ接続 <-> LAN側(NotePC) <-> クロスケーブル(もしくはHUB) <-> 別PC ここでイーサケーブルとして通常のストレートケーブルではなくクロスケーブルを使うことが1つのポイントになる.
手の内を明かしにくい件について - 最速配信研究会(@yamaz)
１年ほど前からWEBサービスの内部アーキテクチャを公開する事例が増えてきた. はてな、イー・マーキュリー共同勉強会 WEB+DB PRESS ライブドア構築ノウハウ大公開 U.S Yahoo!のTechTalk こういう試みは面白いので,ガンガンやってほしいなぁと思う.ただ自分としては 一方的に情報を受け取るのみでこちらからお返しができないことに多少引け目を感じていた. 個人的には自分が得てきた経験や知識をBlogとかに書きたいんだけど, あまりに具体的なことやコアアーキテクチャに関わる部分はいろいろ 会社的に問題ありそうなのでどうにも書けなさそうと考えている. 実際のところこういうジレンマに陥ってる人は多いのかなぁと思う.たいていの 内部アーキテクチャなどをバラしてるBlogは書いてる人が社長とかCTOとかだったり, 会社がそういうのに寛容なケースのみで,一般の社員が書くのはどうにもまず
squid vs apache - 最速配信研究会(@yamaz)
http://blog.livedoor.jp/nipotan/archives/50538571.html を読むとmixiではsquidが一部で使われているようだ.具体的にどこで使われているかはわからないけれど, 当然我々もsquidには目をつけていてapacheのmod_proxyとの比較検討を行ったことがある. その結果squidはスケーラブルな配信サーバを構築するのには向いていないという結論になった. それはこんな理由による. 1. キャッシュされたファイルのインデックスデータとメタ情報をメモリに置くのが無駄 squidはキャッシュされたファイルのインデックスデータとメタ情報をメモリに置く. よって画像が増えれば増えるほどインデックスが大きくなりすぎて,本来使用したい ファイルシステム用のバッファキャッシュが食いつぶされてしまうという結果になった. 実際某サイトでは数十万URL程
画像配信の負荷分散も比較的簡単？（その6） - 最速配信研究会(@yamaz)
画像配信の負荷分散も比較的簡単？（その5）のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. さて前置きが長くなったが,本題に入ろう. アクセスが特定の画像に集中した場合には問題が出ると思うのですが どのように対応したらよろしいでしょうか？ 例えばある画像が1枚某ブログにウプされて 2ちゃんのいろんなスレに画像への直リンクURLが貼り付けられて祭りになり 1台の画像鯖に負荷が集中しさばききれなくなった場合、 先生の方法ではいくら鯖を増設しても負荷は分散されないし アクセスが集中している画像鯖だけ別にDNATやmod_proxy+mod_rewriteとかその他の方法との併用で 負荷分散はできますけど祭りが起きるたびに毎回毎回特定鯖だけネットワークに手を加えるのも めんどくさいと思うのですがこの辺はどのようにしているのでしょうか？』 特定の画像のアクセスが多くなっ
画像配信の負荷分散も比較的簡単？（その5） - 最速配信研究会(@yamaz)
画像配信の負荷分散も比較的簡単？（その4） のつづき. 初めての方は画像配信の負荷分散も比較的簡単？（その1）からどうぞ. 画像配信の負荷分散も比較的簡単？（その3）にて下記のようなコメントをいただいた. アクセスが特定の画像に集中した場合には問題が出ると思うのですが どのように対応したらよろしいでしょうか？ 例えばある画像が1枚某ブログにウプされて 2ちゃんのいろんなスレに画像への直リンクURLが貼り付けられて祭りになり 1台の画像鯖に負荷が集中しさばききれなくなった場合、 先生の方法ではいくら鯖を増設しても負荷は分散されないし アクセスが集中している画像鯖だけ別にDNATやmod_proxy+mod_rewriteとかその他の方法との併用で 負荷分散はできますけど祭りが起きるたびに毎回毎回特定鯖だけネットワークに手を加えるのも めんどくさいと思うのですがこの辺はどのようにしているのでし
画像配信の負荷分散も比較的簡単？（その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に詳しいので,そちらを参照してほしいが,基本的な考え方は今まで負荷分散の考え方となんら変ることはない.つまり
画像配信の負荷分散も比較的簡単？（その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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
