localhost IPCのWindowsでの名前付きパイプと比較して、TCPソケットはどれくらい遅いですか？
私はTCPプロキシをTCPワイルドインターネットからの500から1000のアクティブな接続を処理するサービスの前に置くプロキシを開発しています。
プロキシはサービスと同じマシンで実行されており、ほとんど透明です。このサービスはほとんどの場合プロキシを認識せず、唯一の例外はクライアントの実際のリモートIPアドレスの通知です。
つまり、すべてのインバウンドオープンTCPソケットには、サーバー上に2つのソケットがあります。プロキシのペアの2番目と、プロキシの背後の実際のサービスのソケットです。
2つのプロキシソケットの送信および受信ウィンドウサイズは1024バイトに設定されています。
これに対するパフォーマンスへの影響は何ですか？この構成はどのくらい遅いですか？名前付きパイプ（または他のIPC=メカニズム）を使用するようにサービスを変更するのに多少の努力を払う必要がありますか、localhost TCP IPC？
2つのアプリのマージはオプションではありません。現時点では、2つのプロセス構成に固執しています。
[〜＃〜] edit [〜＃〜]：同じハードウェア上に2つの別個のプロセスを配置する理由は、100％の経済性です。サーバーは1つしかなく、サーバーを増やす予定はありません（お金はかかりません）。
TCPサービスは、期待を超えて成長したVisual Basic 6のレガシーソフトウェアです。プロキシはC++です。VB6コードを書き直して移行する時間、お金、人材はありません。最新のプログラミング環境。
プロキシは、サービスの特定のパフォーマンスの問題を軽減するための試みであり、 DDoS攻撃 私たちは時々得ています。
プロキシはオープンソースであり、 そしてプロジェクトのソースコードです 。
それは同じになります（または、少なくとも測定可能な違いはありません）。 Winsockは、同じホスト上のソケットと通信しているかどうかを知るのに十分賢く、その場合、IPの下のほとんどすべてを短絡させ、データを直接バッファ間でコピーします。名前付きパイプとソケットの観点から、将来異なるマシンと通信できるようにする必要がある場合は、ソケットを選択してください。あなたがそれをする必要は決してないという事実のためにあなたが知っているなら、あなたの開発者が最もよく知っているか、最も快適なものを選んでください。
http://msdn.Microsoft.com/en-us/library/aa178138（v = sql.80）.aspx
まとめさせてください。パフォーマンスが心配な場合は、TCP/IPを使用してください。しかし、非常に高速なネットワークがあり、パフォーマンスを心配していない場合、名前付きパイプはコードを節約できるという点で「きちんとした」ものになります。
言うまでもなく、TCPにこだわると、スケーリングできるものがあり、時間が来たら負荷分散もできます。
乾杯、
私はこのトピックが非常に古いことを知っていますが、それはまだ私にとって関連性があり、おそらく他の人も将来これを見るでしょう。
IPC=同じマシン上のExcel（VBA）と別のプロセスの間に、TCP接続と名前付きパイプの両方を介して）を実装しました。
クイックパフォーマンステストでは、クライアント（Excel）からサーバー（Excelではなく）に26バイトで構成されるメッセージを送信し、他のプロセス（この例では12バイトで構成されています）からの応答メッセージを待ちました。これをループで何回も実行し、平均実行時間を測定しました。
TCP localhost（Windows 7、fastpathなし）では、1つの「会話」（要求+応答）に約300〜350マイクロ秒かかりました。特に、データの送信は非常に遅くなりました（26バイトの送信に時間がかかりました） TCP経由で200マイクロ秒）名前付きパイプでは、1つの会話に平均で約60マイクロ秒かかりました。
なぜその差が大きかったのか、私には完全にはわかりません。これをテストした企業環境には、厳密なファイアウォール、パッケージ検査などがあります。そのため、[〜＃〜] think [〜＃〜]これは、localhostベースの= TCP接続はセキュリティ対策を経て大幅に速度が低下しましたが、名前付きパイプ接続はそうではありませんでした。
TL：DR：私の場合、名前付きパイプは、TCP小さいパッケージの場合はまだ5-6倍高速でした（大きいパッケージではまだテストしていません）
説明するシナリオでは、ローカルTCP接続がボトルネックになることはほとんどありません。もちろん、ある程度のオーバーヘッドが発生しますが、CPUがすでにホットになっていない限り、これは無視できるはずです。
推測では、サーバーのCPU使用率が通常50％未満（プロキシが適切な場合）であれば、ローカルTCP接続に関連するオーバーヘッドを最小限に抑えることを心配する価値はありません。
CPU使用率が定期的に80％を超えている場合は、おそらくプロファイリングを行う必要があります。プロキシが存在する場合と存在しない場合のCPU負荷（または、意味のある方法で測定できる場合はパフォーマンス）を比較することから始めます。プロキシが何らかの複雑な処理を行っている場合を除き、余分なTCP接続に関連するオーバーヘッドは、プロキシによって導入される総オーバーヘッドのかなりの部分である可能性があります。より効率的な形式のIPCを使用することでどれだけの利益が得られるかを予測します。
同じマシンにプロキシを配置する理由は何ですか？
とにかく：
IPC、TCP/IPにはいくつかの方法があり、名前付きパイプは速度と複雑さにおいて同等です。拡張性が高く、オーバーヘッドがほとんどないものが本当に必要な場合は、共有メモリを使用します。ポインターを進めるためのロックフリーアルゴリズムと組み合わせて使用するのが最適です（または、リーダー（プロキシ/サービス）およびライター（サービス/プロキシ）ごとに1つのバッファーを使用します）。