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)
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
この投稿は、私が去年OSCONで行ったプレゼンテーションを基に作成しています。プレゼンよりは簡潔に編集し直し、プレゼン後にいただいたいくつかのフィードバックに応える形で記事を書いています。 Go言語に関してよく言われるのは、Go言語はサーバでうまく機能し、静的なバイナリや強力な並行処理、高いパフォーマンスを見せくれるということです。 この投稿では、その後半の2つの項目に関して焦点を当てます。プログラマとってGo言語とそのランタイムは、スケーラブルなネットワークサーバをスレッド管理やブロッキングI/Oを気にせずに書くのにどんなに有効かを説明していきます。 効率的なプログラミング言語に関しての議論 技術的な話に入る前に、Go言語をターゲットにしたマーケットを説明する2つの議論に関してお話したいと思います。 ムーアの法則 画像は以下より引用； 2005年5月にHerb Sutter氏が書いたDr
C10K 問題、実は理解していない
お願い 「C10K 問題とは何か」がわかる方は是非 Issue や Twitter などで教えてください。 追記: 自分の立場 1req ごとに 1 native thread を割り当てていたら、クライアントの数が増えれば増えるほど負荷が高まるのは当然だ。ただハードウェアの性能的に余裕があっても性能が劣化することがあり、それを C10K 問題と呼ぶ。C10K 問題は fd, pid の枯渇、スレッドを固定長サイズで確保することによるメモリの無駄遣い、コンテキストスイッチコストを含む。これを解決する方法が 1req ごとに 1 native thread を割り当てない技術で、シングルスレッド+イベントループ+IO 多重化といったテクニックや M:N モデルにつながる。 追記: @naoya_ito さんに解説してもらった当時の歴史的背景 https://twitter.com/naoya
C10K 問題 (the C10K problem) は1999年に Dan Kegel が発表した文章、ならびにそこで提示された「問題」です。文章はその後も2000年代前半に何度か更新されているのですが、さすがに令和に読み返すと、当初の問題意識がわかりにくいところがあります。 2000年からの10年は、 ソフトウェア面では、select(2), poll(2) にかわる新しいシステムコールの実装と、それを使ったアプリケーションの普及 ハードウェア面では、x86 アーキテクチャの64ビット移行、仮想化命令の追加と、マルチコア化 さらにそこにクラウドも登場する、面白い時代でした。ここでは、それらの出来事を中心に、さらに、当時の雰囲気をつたえるような日本国内のブログやインタビュー記事をまとめることで、C10K 問題が、さまざまな側面から解決されていく流れを説明したいと思います。 書き足したいと
唐突ですが、一回目の記事を書きます！ 今回は、主にウェブサーバー、具体的にはLinuxのSO_REUSEPORT（プログラミング言語としてはC言語)の話題になります。背景として、弊社では、広告配信がいわゆるネイティブアプリケーションであるため、ウェブサーバーの開発を行っているといったことが挙げられます。そもそも今回の記事を書いたきっかけは、弊社でSO_REUSEPORTを使用し始めており、それについて紹介したいと考えたからです。 特にC10K問題については TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと が詳しいので今回は説明を省略します。 また、Linux（正確にはKernel 3.9以降）におけるSO_REUSEPORTについては、 或るプログラマ
スタバ方式で「C10K問題」を解消
WebアプリケーションサーバーソフトのNode.jsには、これまでのWebアプリケーションサーバーとは全く異なる四つの特徴がある（図1）。（1）多くのアクセス要求を処理できること、（2）JavaScriptでアプリケーションを開発できること、（3）アドオンが充実していること、（4）様々な種類のサーバーとして動作すること、である。これらの特徴を順に見ていこう。 一つめの特徴は、ピグライフのように1万台規模のクライアントからのアクセス要求をさばけることだ。従来のWebサーバーとは異なる「ノンブロッキングI/O（インプット/アウトプット）」と呼ばれる考え方を取り入れることで、これを実現する。 この考え方は、スターバックスの接客方式をイメージすると分かりやすい。客はレジで注文と支払いを済ませると、配膳口近くで注文した飲み物ができるのを待つ。飲み物ができたかどうかに関係なく、レジでは次々と注文を受け
はじめに 前回は、複数のファイルディスクリプタを一元管理する「多重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コマンド
C10K問題とは - ablog
いまさらながら。そして一部妄想系のメモ。 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと。 万を超える接続に対応するプロセスやスレッドを生成するとメモリ上にプロセスやスレッドの管理領域が確保され、使われるメモリサイズもばかにならない。プロセスとスレッドでは差があり、1接続あたり1プロセス生成するほうがメモリやファイルディスクリプタなど使うリソースが大きくなるはず。 プロセス数、スレッド数、ファイルディスクリプタ数などの上限に達してしまうという問題もある。このあたりは実装依存だったり設定を変えれば増やせたりすると思う。数を設定で増やせても、大きくなると探索が遅くなったりして性能に影響する可能性もありうると思う。 第4回で触れましたが、select(2), poll(2)は、管理するディス
独断と偏見で、ありとあらゆる物（主にライトノベル・コミック・アニメ・Geekネタ）のレビューを偽った感想を書いてるBlog＝レビュー＋ブログ＝レビログ WindowsではIOCompletionRoutineを使え XP以前の2000の時代から 業務レベルではwinsockとか、旧時代のLinuxベースのソケット処理では 追いつかず、 Windowsカーネルのネイティブを使わないと、 という流れは昔から 2003サーバー以前の2000の時代から ついでに、そういったサポートが受けられるIISがApacheよりも処理速度が速い というのも最近の商業系プログラマの定石 結局Webの世界では数百万セッションで莫大とかいわれますが・・・ NTTなどの電話交換機の世界では、その数百万なんて地域レベルなわけで・・・ 全国レベルでは・・・もう気が遠くなるぐらいのユーザ数というか７千万加
2008年5月15日 at 12:00 午前 さて、おまたせ致しました。 本日より、JJUGで発表したGrizzlyについて紹介したいと思います。 まず、Grizzlyって聞いたことありますか？ 「GrizzlyはGlassFishコミュニティの中のサブプロジェクトの１つで JavaのNew I/Oを使って記述された汎用的なネットワークサーバエンジンです。」 Project Grizzly : https://grizzly.dev.java.net/ Project Grizzlyによって開発された成果物（ネットワークサーバエンジン）は GlassFishとは独立して単体で使用することができます。また、Grizzlyは独自の進化を遂げていっています。現在、Grizzlyの最新バージョンは1.7.3.1です。 今回紹介するGrizzlyは少しバージョンが古いのですが、GlassFish v
C10K問題 - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "C10K問題" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2019年9月） C10K問題（英語: C10K problem）とは、Apache HTTP ServerなどのWebサーバソフトウェアとクライアントの通信において、クライアントが約1万台に達すると、Webサーバーのハードウェア性能に余裕があるにもかかわらず、レスポンス性能が大きく下がる問題である。 原因[編集] この現象の原因は主に2019年現在も広く用いられているApache HTTP Server(以下「Apache」)の駆動方式にある。 Apacheはクライアントの接
net-snmpのC10K問題(後編)
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. なぜsnmpdがリクエストに答えないのか突き止めるべく、まずprstat (topみたいなやつ)で様子を見てみたら、snmpdが3%以上のCPU使用率でトップに君臨していました。この使用率は32CPUで計算されているので、本当は8コアのUltraSPARC T1にはかなりの重荷です。 いったい何をそんなに忙しくしているのかとtrussで追ってみたら、ひたすらファイル記述子6番からgetmsgでメッセージを読んでいました。このメッセージの読み込みが忙しくてリクエストに答えるひまがないようです。 こんなときはlsofがあると簡単なんですが、インストールしていなかったので
CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
nginxはApacheでC10K問題が起こったことにより開発され始めました。 C10K問題とは、簡単にいうとクライアントが多すぎてサーバーがパンクすることです。 サーバーにクライアントが接続すると、worker/threadが発生します。worker/threadとはクライアントが仕事が来たら働くが、来ない場合は待機するというものです。 workerはメモリをある量だけ確保します。これによって一定数以上のクライアントが接続するとサーバーが食い尽くされます。 この現象が起きるのがだいたいClientが10Kilo個の時におこるという意味でC10K問題と言います。 実際は他にも原因があるようですが、細かいところまではわかりませんでした。 わかる方は http://www.aosabook.org/en/nginx.html を読んでいただくとわかると思います。 C10K問題の解消 上記の問題
C10K問題 – 寺田 佳央 – Yoshio Terada
Grizzlyの概要 : C10K問題に対応するGlassFish(Grizzly) さて、おまたせ致しました。 本日より、JJUGで発表したGrizzlyについて紹介したいと思います。 まず、Grizzlyって聞いたことありますか？ 「GrizzlyはGlassFishコミュニティの中のサブプロジェクトの１つで JavaのNew I/Oを使って記述された汎用的なネットワークサーバエンジンです。」 Project Grizzly : https://grizzly.dev.java.net/ Project Grizzlyによって開発された成果物（ネットワークサーバエンジン）は GlassFishとは独立して単体で使用することができます。また、Grizzlyは独自の進化を遂げていっています。現在、Grizzlyの最新バージョンは1.7.3.1です。 今回紹介するGrizzlyは少しバージョ
net-snmpのC10K問題(前編)
日本最強の看板を下ろしたミラーサーバftp.jaist.ac.jpの管理者の一人が、 このサーバにまつわるよしなしごとを語ります。 English versions of some posts on another blog. 昔C10K問題というのが話題になりました。Y2K問題をもじった名前なので2000年から数年間くらいですね。インターネットのバックボーンが1Gbpsに到達した。GbEを備えた1GHzのCPUのサーバが安価に手に入るようになった。しかし、10,000クライアントを同時にさばこうとすると、ハードウェアではなくOSがボトルネックになるという問題です。 当時はsendfileのようなゼロコピーsendのシステムコールはありませんでした。大量のスレッドを効率よく実行できるのは一部の商用OSだけでした。大量のファイル記述子の状態変化を効率よく待つ仕掛けもありませんでした。これでは
http://www.atmarkit.co.jp/news/analysis/200701/09/c10k.html クライアント1万台問題。Cometなどでクライアント数が多くなると、Webサーバがパンクするという話題。 追記： Web2.0とC10Kに関する数々の誤解 naoya: C10K
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web2.0の先にあるC10K問題 ― ＠IT
イベントループなしでのハイパフォーマンス – C10K問題へのGoの回答 | POSTD
令和にふりかえる C10K 問題
C10K問題の今と未来 - geniee’s tech blog
ファイルディスクリプタについて（6） ～多重I/Oの性能とC10K問題
レビログ::C10K問題？・・やはり、Webで叫ばれるのは商用ベースで話題になってからか・・・
Grizzlyの概要 : C10K問題に対応するGlassFish(Grizzly)
ファイルディスクリプタについて（6） ～多重I/Oの性能とC10K問題
NginxがどのようにしてC10K問題に対応しているのか？ - Qiita
Web2.0の先にあるC10K問題 - www.textfile.org