ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
