TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
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)
マルチ・スレッド（multi-thread）プログラミングの落とし穴、その１（かもしれない）
ここのところ技術系ブロガーの間で話題になっている、「C10K問題（参照１、参照２）」は、ひとことで言えば、多くのウェブ・サーバーで採用されているmulti-threadやmulti-processに頼った（もしくは頼りすぎた）多重処理というアーキテクチャーのスケーラビリティに対する極めてまっとうな警告である。 この話は、決して最近になって始まった話ではなく、パソコン業界ではパソコンのOSにpreemptiveなマルチタスクが導入されはじめた９０年代の前半から、さらに遡ると、DECを中心にテクノロジーが進化したミニコンの時代から、ソフトウェア・エンジニアたちの間で盛んに討論されてきたテーマである（さすがに、メインフレーム時代の話は私は知らない）。 十数年を経た今でも、いまだに決着が付いていないこの問題は、私の大好きなテーマの一つでもあるし、もし私が博士号をこれから取得しようとするのであれば、
「Web2.0とC10Kに関する数々の誤解」の誤解 - 最速配信研究会(@yamaz)
前エントリWeb2.0とC10Kに関する数々の誤解に関してはいろいろツッコミをいただいた(ありがとうございます). 名無し 『誤読した上にえらそうに微妙な解説するあたり恥ずかしすぎます。』 えらそうで微妙な解説なのはまぁそうなので否定しないが,誤読とはなんのことだろう? こういうときは今はやりの「スルー力」を発揮するのが大人のインターネットかと思ったけれど, 私のBlogが扱う内容は非常に狭く,さらにそれに対して突っ込もうと思う人の 意見はなにかしらの真実が含まれるはずと考えていたところ,下記エントリがあった. 元記事の人は上でいう 3，6 あたりを書いていて，id:yamaz さんは 3 するなら 4 とか常識だろ，と噛みついているように読めました。. なるほど,私の前エントリは@ITの元記事に対して噛みついているように 読めるようだ(言われてみればたしかにそう読める). 実際の所は元記
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
