多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ
Being fast doesn't make you scalable. But it does mean you can handle more capacity with your current infrastructure. Take a look at this diagram of request handlers. You can see that it takes 13 request handling threads to process this amount of load. In the next diagram, the requests arrive at the same rate, but in this picture it takes just 200 milliseconds to answer each one. Same load, but on
最近Erlangを勉強中なのだけど，かなり良い感触． メジャーじゃない言語（C/C++，Perl，Java，PHP，Rubyくらい？）は，興味を持っても，実際に業務で導入する，というところまでは行かないのだけど，Erlangは実際に使いたいと思うほど． MLでErlangの話の資料が公開されていて， Threads is evil. Processes are ugly. State machines send you mad. ということで，Erlang良いよ，という内容． 多数のリクエストを扱うようなサーバアプリケーションを作る場合，スレッドは見つけにくいバグがよく起こる上にそこまでスケールしないし，マルチプロセスは遅い＆スケールしない． C10K問題と言われていて，解決する方法としては，ノンブロッキング呼び出しとか非同期呼び出しで自前で各コネクションの状態を管理してがんばるしかないわ
訳してみた. また YukiWiki に置かせてもらってます. 元ネタは "The C10K Problem". 年末年始に訳しかけたけれど時間切れで放置してあった. 今日はいまいち新しいことをやる気がおきず, 外出する財力もなく, 後始末でもするかと再開して完了. 引用される割に読まれていないと感じたのが訳そうと思った動機. 資料的価値は高いのかもしれないけれど, たしかに読み物としてはあまりよくない. 特に後半はトピックの列挙と箇条書きばかりで訳すのは退屈. まあ, 仕方ないんだけど. 資料だし... 読み物として面白くないものは訳すのも辛いと学びました. 長いのと退屈なのとでかなり雑になってしまった. 機械翻訳に毛が生えたものと割り切り, 気になる部分は添削してもらえると嬉しゅうございます. あらあらかしこ.
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき本 I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)
This week I helped dealing with performance problems (part MySQL related and part related to LAMP in general) of system which does quite a bit of content delivery, serving file downloads and images – something a lot of web sites need to do these days. There were quite a bit of mistakes in design for this one which I though worth to note, adding some issues seen in other systems. Note this list app
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
