Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか

多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか？ echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ

[castaneai]

スループットに関してはそこまで差がなくなってきてる。memoryについてはどうなんだろう

[kyab]

もはや非同期APIもスレッドもあんま変わんねーじゃんって話。非同期API(イベントモデル）使い出すと、File I/Oも非同期の必要があるし、ポータビリティが、、って感じ。でもlibuvでかいけつじゃないの？ケースバイケース？

[myfinder]

イベント駆動がんばりたい...

[syuu1228]

Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか

[kazuhooku]

node.jsの立場って…

[yass]

"1コネクション1スレッド、という選択肢が現実的 / マルチプロセッサ対応は必須ですから、マルチスレッド（マルチプロセス）＋イベント駆動の二階建てにするよりも、1コネクション1スレッドのモデルの方が必然的に単純"

[mkusunok]

1:1スレッドもそんなに性能は悪くないじゃん、移植性とか考えるとこっち

[r-west]

m

[iww]

自分の環境でもいっかい実測しないとダメか。 面倒くさいな

[rna]

「ロックの競合が問題になる場合や、最後の一滴までサーバのリソースを搾り取りたい場合」でなければper-threadでOK、という話。