Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、1セッション1スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを1スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
今回はLinuxのネットワークチューニングの一部を書きます。 このチューニングはkernelのバージョンに(2.6.17以前が前提 )依存するので、やった方がいい場合とAutoチューニングでお任せの方がいい場合があるので注意が必要です。 また、チューニングの目的がはっきりした方がよいでしょう。やはりチューニングの目的は巨大なファイルを転送する処理が多いか少ないかまた、その頻度だと思います。 もし、それほどのアクセス、やり取りするファイルが少ないならばやらない方がいい場合もあります。 まず、基本はネットワークの高速化に役立つパラメータはNetwork Bufferというものです。 デフォルトでは、例えばtcp bufferサイズは小さいのでこれを大きくすると高速化が狙えます。 それでは、実際に現在設定されているサイズを確認してみましょう。 (tcp_memory) $ cat /proc/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く