コアの数と スレッド数とイベント処理

マルチコア時代のサーバ設計について - Happy Hacking Diary
Ringo's Weblog: Event-driven Programming for Robust Software

イベント処理というか、スレッドに対するファイバー処理ね。
マルチファイバー（イベントドリブン）とスレッド処理の違いは、
自分でファイバーの切り替えようのスケジューラーを書くか書かないか？
という差分である。

このファイバースケジューラーが、OSが用意したスレッドスケジューラーよりも高速である場合
ファイバーの方が高速になり、遅い場合スレッドの方が高速になる。

したがって、マルチスレッドよりも遅い、ファイバーもあり得るし、スケジューラーを最適化することによりマルチスレッドよりも高速なファイバーを書くことも出来る。

一般的にスケジューラーは、イベントのタイミング、メモリなどにより、最適なチューニングが異なるので
OSが提供するスレッドスケジューラーは汎用的な物になり、プログラマが書き起こすファイバースケジューラは特化した物になる。

したがって、一般的にはファイバーの方が高速だが
腕の悪いプログラマが書けば、スレッドの方が高速になる。

また、ファイバースケジューラーを書く場合にも、そこで使うイベントドライバーは最終的にはOSコールやドライバーコールとなる。
ここでOSが介在するので、そのドライバーやコーリーの性能によっては、スレッドを使った方が相性がよいので高速となることもある。

ようするに、データの状況、OSの実装に依存するので、　どちらがよいかというのは一概には言えない。

ただし、現在の一般的なOSに関して言えば、　数十万セッションを耐えようと思ったら、一般的なOSは数十万スレッドを駆動するようなスレッドスケジューラーを持っていないことが多いので、ファイバーを書いた方が高速となる。
しかし、大概のOSはイベントドライバーの性能がスレッドを使った方が若干速い実装になっていることもある（というかスレッドを前提意図した実装になっている）という事があるので。

1コア当たり、数個〜十数個のスレッドを用意し、そのスレッドが数千〜数万のセッションを分散してイベントで処理するイベントドライバ型駆動するという　ファイバーとスレッドの合成スケジューラーを書くのが2008年現在当たりでは妥当な速度になる。

また、この場合スレッドロックは、OSコールになり重いし、スピンロックもまた、重いので、スケジューラー側で工夫をして、1イベント処理中はロック無しで走りきり、最後の最後の1イベント終了時に処理データをメインデータにマージするというトランザクション式のデータ処理方式をとった方が、ロックの回数が高々スケジューラの1回になるので、高速になることが多い。

他、その他、歴史的なファイバー動作やスケジューラ動作をちゃんと理解したプログラマが書けば、イベントドリブン型の方が高速なのは自明。

ただし、OSの動作そのほかをきちんと勉強しないと行けないので初心者はスレッドで書いた方が安全。

以上、C10Kを越えるサーバーを研究所で作って納めたときのノウハウより。　というかこの手のイベントドリブン型はWindwos Serverのカーネルコールが意外と良くできているので、みてみるといいよ。実はWindows serverはSynを送ったらACKをまたずに処理を戻すとかできるから、Synだけ何十万個も打つとかその逆とかできるって知ってた？もちろんTCPスタックを独自実装ではなくWindows server のTCPスタックにその機能があるって意味ね。

ただ、その処理は2004年次にはマニュアルにはなかったし、今もないと思う。でも、パラメータ一覧を見て、パラメータの組み合わせを考えれば、出来ることは自明なので、探せばいいと思うよ。

あと、DNSのコールは最悪30秒とか待たされるので自前でDNSキャッシュを用意すると良いと思うよ。OSの重いDNSコーラーなんか信じちゃダメ。

数年前の時点で、数年前のハードと研究レベルで、当時のDELLの10万の安パソコンでベンチとったら１時間当たり一千万セッション/1台とか、そういう値なので、いまなら、実用レベル　セキュリティとかいろんな機能をもりこんで、できるんじゃない？　C10K程度は　とかそのぐらいとかそんなきもち。

まぁ、やってみないとわからんけど、コア数とスレッド数とファイバ数に関しては　１：１０：10000ぐらいじゃない、アバウトとかそんな気持ちでいますが、まぁ、どうなんでしょうね。

戯れ言ですから、所詮は。

あと、ココラ辺の話は10年ぐらい前の論文をあさればいいんじゃないかとおもう。

真面目に、この手の古典技術がロステク化してるなぁ