ファイルディスクリプタについて（6） ～多重I/Oの性能とC10K問題
はじめに 前回は、複数のファイルディスクリプタを一元管理する「多重I/O」機能について紹介しました。今回は、多重I/Oの性能と問題点について検証していきます。 連載概要 第1回：ディスクリプタの概要 第2回：イベント用ディスクリプタ「eventfd」の特徴 第3回：タイマー用ディスクリプタ「timerfd」の特徴 第4回：シグナル用ディスクリプタ「signalfd」の特徴 第5回：多重I/O「Multiplex I/O」の種類の特徴、使い方 第6回：多重I/Oの性能とC10K問題 第7回：シグナル駆動I/Oの特徴、使い方 第8回：非同期I/O「Asynchronous I/O」の使い方と性能差 第9回：ファイルディスクリプタパッシングの特徴、使い方 サンプルプログラムは100行前後程度までは画面に記載します。全プログラムは圧縮してページ上部よりダウンロード可能にしています。makeコマンド
みかログ: ErlangでComet
telnet接続で計算問題を出題する (fujishinko 雑記帳) jquery history プラグインアップデート (みかログ) Logicool MX Revolution (RedWing's Blog) Erlang で memcached を作ってみました。 (DSAS開発者の部屋) [erlang]proc_lib で echoserver を書き直した (cooldaemonの備忘録) [security] PHPのセキュリティ続き (Angelic Wing) [Erlang][Programming][Erlday][Comet][Yaws] Erlang for everyday use (3) (ZHlog) [Prog (ひおにっき) [Prog (ひおにっき) ErlangからPerlを使う (404 Blog Not Found) ErlangでCome
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の元記事に対して噛みついているように 読めるようだ(言われてみればたしかにそう読める). 実際の所は元記
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
最速配信研究会 - Web2.0とC10Kに関する数々の誤解
Web2.0 = Ajax/Cometなの？とかプロセスIDは今でも16ビットなの？とかはサテオキ、 個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 AjaxやCometなどのクライアント側技術に伴うサーバ側の問題に関していろいろ誤解があるようなので,書いておきたい.きっとlingrの中の人はこの記事読んでニヤニヤしてるはず. 以下、記事にないことも書いてあるのでそのつもりで. 誤解その1 AjaxによるWebアプリの台頭でサーバ側の負荷が増大する Ajaxの典型的な使い方はサーバに問い合わせてページの一部分だけを 変化させるというモノだ.これはページ全体を書き換える従来の方法と違い, すでに
Web2.0の先にあるC10K問題 ― ＠IT
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
