Linuxネタ・テクニック・話題のポータル

興味深い。リモートのホストへの転送でブロックサイズが小さいときに性能が低下しないのは、システムコール呼び出しはcswに比べると大したオーバーヘッドじゃないからってことなんだろうなあ。　 [ nippondanji ]

サーバとベンチマークプログラムの両者を同一ホスト上で動かした場合のみ、コンテクストスイッチが頻発しパフォーマンスが低下するケースがあったと記憶しています。　 [ HISAMATSU ]

ためになる　 [ iakio ]

アプリケーションプログラマの視点から見ると、ホスト間のTCP通信はスループット重視だが、同一ホスト間の通信はレイテンシ重視　 [ zorio ]

dev:Kazuho@CybozuLabs:TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（&サーバのベンチマーク手法の話）:　 [ bsiyo ]

同一ホスト上の通信ではブロックサイズを小さくするとwrite（2）とread（2）のオーバーヘッドのため速度低下。　 [ sukepyon ]

それですねーRT@sh2nd:これ?　 [ yappo ]

原因は、同一ホスト上の通信では、送信プロセスがwrite（2）を呼ぶたびにコンテクストスイッチが発生し、受信プロセスが起き上がってread（2）でデータを受信するところにあります　 [ tgk ]

unixdomainsocket　 [ hirose31 ]

Kazuho@CybozuLabs:TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（&サーバのベンチマーク手法の話）　 [ nilab ]

サーバプログラムはリモートホストからベンチマークすべき　 [ lamanotrama ]

全く理解できない。ちゃんと勉強しる⇒読み直して大分分かった　 [ kenji-u ]

計測誤差か　 [ mattn ]

Kazuho@CybozuLabs:TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（&サーバのベンチマーク手法の話） TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite（2）で書き... はてなブックマーク-Kazuho@CybozuLabs:　 [ dann ]

『アプリケーションプログラマの視点から見ると、ホスト間のTCP通信はスループット重視だが、同一ホスト間の通信はレイテンシ重視だ、と理解しておけばいいのかもしれません。』　 [ monjudoh ]

C/Sが同一ホストで小さいパケットで通信するとコンテキストスイッチでパフォーマンスが悪くなる。リモートだとそれはないけど、write（2）で512よりもでかいのを渡しても結局NICが512bytesくらいで区切っちゃったりするのかな?　 [ karronoli ]

データ転送時間とブロックサイズの関係　 [ toremoro ]

アプリケーションプログラマの視点から見ると、ホスト間のTCP通信はスループット重視だが、同一ホスト間の通信はレイテンシ重視だ　 [ hogshead ]

ほほー　 [ jt_noSke ]