How slow are TCP sockets compared to named pipes o

问题:

I am developing a TCP Proxy to be put in front of a TCP service that should handle between 500 and 1000 active connections from the wild Internet.

The proxy is running on the same machine as the service, and is mostly-transparent. The service is for the most part unaware of the proxy, the only exception being the notification of the real remote IP address of the clients.

This means that, for every inbound open TCP socket, there are two more sockets on the server: the secondth of the pair in the Proxy, and the one on the real service behind the proxy.

The send and recv window sizes on the two Proxy sockets are set to 1024 bytes.

What are the performance implications on this? How slow is this configuration? Should I put some effort on changing the service to use Named Pipes (or other IPC mechanism), or a localhost TCP socket is for the most part an efficient IPC?

The merge of the two apps is not an option. Right now we are stuck with the two process configuration.

EDIT: The reason for having two separate process on the same hardware is 100% economics. We have one server only, and we are not planning on getting more (no money).

The TCP service is a legacy software in Visual Basic 6 which grew beyond our expectations. The proxy is C++. We don't have the time, money nor manpower to rewrite and migrate the VB6 code to a modern programming environment.

The proxy is our attempt to mitigate a specific performance issue on the service, a DDoS attack we are getting from time to time.

The proxy is open source, and here is the project source code.

回答1:

It will be the same (or at least not measurably different). Winsock is smart enough to know if it's talking to a socket on the same host and, in that case, it will short-circuit pretty much everything below IP and copy data directly buffer-to-buffer. In terms of named pipes vs. sockets, if you need to potentially be able to communicate to different machines ever in the future, choose sockets. If you know for a fact that you'll never need to do that, pick whichever one your developers are most familiar or most comfortable with.

回答2:

For anyone that comes to read this later, I want to add some findings that answer the original question.

For a utility we are developing we have a networking class that can use named pipes, or TCP with the same calls.

Here is a typical loop back file transfer on our test system:

TCP/IP Transfer time: 2.5 Seconds
Named Pipes Transfer time: 3.1 Seconds

Now, if you go outside the machine and connect to a remote computer on your network the performance for named pipes is much worse:

TCP/IP Transfer time: 12 Seconds
Named Pipes Transfer time: 2.5 Minutes (Yes Minutes!)

I realize that this is just one system (Windows 7) But I think it is a good indicator of how slow named pipes can be...and it seems like TCP is the way to go.

回答3:

I know this topic is very old, but it was still relevant for me, and maybe others will look at this in the future as well.

I implemented IPC between Excel (VBA) and another process on the same machine, both via a TCP connection as well as via Named Pipes.

In a quick performance test, I submitted a message than consisted of 26 bytes from client (Excel) to server (not Excel), and waited for the reply message from the other process (which consisted of 12 bytes in the example). I executed this a ton of times in a loop and measured the average execution time.

With TCP on localhost (Windows 7, no fastpath), one "conversation" (request+reply) took around 300-350 microseconds. Especially sending data was quite slow (sending the 26 bytes took around 200microseconds via TCP). With Named Pipes, one conversation took around 60 microseconds on average - so a LOT faster.

I'm not entirely sure why the difference was so large. The corporate environment I tested this in has a strict firewall, package inspections and what not, so I THINK this may have been caused as even the localhost-based TCP connection went through security measures significantly slowing it down, while named pipe ones likely did not.

TL:DR: In my case, Named Pipes were around 5-6 times faster than TCP for small packages (have not tested with bigger ones yet)

回答4:

http://msdn.microsoft.com/en-us/library/aa178138(v=sql.80).aspx

Let me sum it up for you. If you are worried about performance then use TCP/IP. But if you have a really fast network and your not worried about performance then Named Pipes would be "neat" in that it might save you some code.

Not to mention, if you stick to TCP then you will have something that can be scaled, and even load balanced when the time comes.

Cheers,

回答5:

In the scenario you describe, the local TCP connections are very unlikely to be a bottleneck. It will introduce some overhead, of course, but this should be negligible unless your CPU is already running hot.

At a guess, if your server's CPU usage is normally below 50% or so (with the proxy in place) it isn't worth worrying about minimizing the overhead associated with the local TCP connections.

If CPU usage is regularly above 80% you should probably be doing some profiling. I'd start by comparing the CPU load (or, better still, the performance, if you can measure it meaningfully) when the proxy is in place to when it isn't. Unless the proxy is doing some complicated processing, the overhead associated with the extra TCP connections is probably a significant fraction of the total overhead introduced by the proxy, so that should give you at least an order-of-magnitude estimate of how much you'd gain by using a more efficient form of IPC.

回答6:

What is the reason to have a proxy on the SAME machine, just curious?

Anyway:

There are several methods for IPC, TCP/IP, named Pipes are comparable in speed and complexity. If you really want something that scales well and has almost no overhead: use shared memory. Best used in combination with a lock free algorithm for advancing the pointers (or use one buffer for each reader (the proxy/the service) and writer(the service/the proxy)).