RailsConf1日目 Scaling a Rails Application from the Bottom Up
RailsConf 1日目はTutorial/Guidebook day。 registrationをすませた後は”Scaling a Rails Application from the Bottom Up“に参加してみる。 その名の通り、下位層からRailsのスケーリング話。 スピーカーはJoyentのCTO Jason Hoffman。 前半、Guidebookの写真とか撮っててあんまり聞いてなかった Joyentの構成とハードの話し OSはLinux/FreeBSD/Solaris ディスクはSunFire X4500(RAIDZ2+1 likes RAID6+1) and NetApp NAS ベンチマークで10,000op/sec, 80-100Mb/s ハードウエア ベンダーはDELL > HP > Sun DELLは直接色々してくれるけど、Sunはリセラーに丸投げ 本体が$
PoCo::HTTP による Comet チャットサーバのスケーラビリティ - 酒日記 はてな支店
せっかくのイベントドリブンフレームワークな POE ですから Comet でチャットをやってみようかと。 http://d.hatena.ne.jp/dayflower/20061116/1163663677 こちらの POE::Component::HTTP による Comet チャットサーバですが、どのぐらいの接続まで耐えられるのか? 実験。 クライアントとして、HTTP::Async を使って同時接続を張りまくるスクリプトを用意。 #!/usr/bin/perl use HTTP::Async; use HTTP::Request; use Time::HiRes qw/time/; use strict; my $slots = shift || 20; my $async = HTTP::Async->new( slots => $slots ); my $req = HTTP:
最速配信研究会 - Web2.0とC10Kに関する数々の誤解
Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに
画像配信の負荷分散も比較的簡単？（その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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
