Thread: Performance: Unix sockets vs. TCP/IP sockets
What performance penalty can I expect when going over TCP/IP sockets instead of Unix sockets? I might have to do that because of some odd configuration on the server that my app will run on. The application (Apache/PHP) is on the same physical host as the Postgresql server. Ta, Frank
Frank Joerdens <frank@joerdens.de> writes:
> What performance penalty can I expect when going over TCP/IP sockets
> instead of Unix sockets?
On a properly designed kernel, there shouldn't be any measurable
performance difference between a local TCP connection and a Unix-socket
connection.
There are not-so-well-designed kernels out there, but I forget which
they are (and you didn't bother to specify your platform anyway).
If you want a reliable answer, fire up a data-transfer-intensive task,
say a COPY OUT of a large table, and time it both ways.
regards, tom lane
On Thu, Jan 25, 2001 at 11:07:19PM -0500, Tom Lane wrote: > Frank Joerdens <frank@joerdens.de> writes: > > What performance penalty can I expect when going over TCP/IP sockets > > instead of Unix sockets? > > On a properly designed kernel, there shouldn't be any measurable > performance difference between a local TCP connection and a Unix-socket > connection. Ah. That's good hear. I'd heard that TCP/IP was _significantly_ slower than Unix sockets. But maybe that was just Linux. > > There are not-so-well-designed kernels out there, but I forget which > they are (and you didn't bother to specify your platform anyway). It's Solaris 7 (cf. the current thread in hackers). > > If you want a reliable answer, fire up a data-transfer-intensive task, > say a COPY OUT of a large table, and time it both ways. I might try that in a couple of weeks' time when the current rush is over. Ta, Frank
>>>>> "Frank" == Frank Joerdens <frank@joerdens.de> writes:
Frank> On Thu, Jan 25, 2001 at 11:07:19PM -0500, Tom Lane wrote:
>> Frank Joerdens <frank@joerdens.de> writes: > What performance
>> penalty can I expect when going over TCP/IP sockets > instead
>> of Unix sockets?
>>
>> On a properly designed kernel, there shouldn't be any
>> measurable performance difference between a local TCP
>> connection and a Unix-socket connection.
Frank> Ah. That's good hear. I'd heard that TCP/IP was
Frank> _significantly_ slower than Unix sockets. But maybe that
Frank> was just Linux.
I must admit from my mysql days that this comment was made, but we are
probably talking a couple of years ago, which would be Linux
2.0. Whether 2.2 was better, or 2.4 is I am completely clueless. Here
is an excerpt from the mysql manual (heres hoping I won't be lynched
for posting this :-) :-
You get the fastest executable when you link with -static. Using
Unix sockets rather than TCP/IP to connect to a database also
gives better performance.
and :-
Here is a list of some mesurements that we have done:
<snip>
If you connect using TCP/IP rather than Unix sockets, the result
is 7.5% slower.
<snip>
I searched on google for references to this, plenty of mysql hits, but
also other systems, for example Cold Fusion has this to say :-
In our testing, the use of the newly implemented TCP Network
socket communication will degrade performance by 10-15% or more
from the default Unix Domain socket
(although this may be because of Cold Fusion itself).
I must admit most of the other references to slower TCP than Unix
sockets are to older documents. I suppose the easiest thing to do is
setup a test and see for yourself.
Sorry if this is becoming to OT,
Sincerely,
Adrian Phillips
--
Your mouse has moved.
Windows NT must be restarted for the change to take effect.
Reboot now? [OK]
Frank Joerdens <frank@joerdens.de> writes: > On Thu, Jan 25, 2001 at 11:07:19PM -0500, Tom Lane wrote: > > Frank Joerdens <frank@joerdens.de> writes: > > > What performance penalty can I expect when going over TCP/IP sockets > > > instead of Unix sockets? > > > > On a properly designed kernel, there shouldn't be any measurable > > performance difference between a local TCP connection and a Unix-socket > > connection. > > Ah. That's good hear. I'd heard that TCP/IP was _significantly_ slower > than Unix sockets. But maybe that was just Linux. Much as I hesitate to contradict Tom here, I think I need to qualify his statement. For a localhost TCP socket, a write() has to be sent down the network stack and (possibly) split into packets, which are then sent through the routing engine and back up through the stack, flow-controlled, reassembled, and submitted to the receiving socket. Also, ACK packets have to be sent back to the sender through the same tortuous path. For a Unix socket, the write() is merely copied into the socket buffer, and the reader notified that data is ready. Flow control consists of simply blocking the writer if the buffer is full. For bulk data, a Unix socket will almost certainly be faster due to the reduced overhead. For a Postgres connection, query compilation (if needed) and lookup time, plus disk i/o if necessary, will dominate. and you shouldn't see a significant difference between the two types of socket. -Doug
Doug McNaught <doug@wireboard.com> writes:
>> On Thu, Jan 25, 2001 at 11:07:19PM -0500, Tom Lane wrote:
> On a properly designed kernel, there shouldn't be any measurable
> performance difference between a local TCP connection and a Unix-socket
> connection.
> Much as I hesitate to contradict Tom here, I think I need to qualify
> his statement.
> For a localhost TCP socket, a write() has to be sent down the network
> stack and (possibly) split into packets, which are then sent through
> the routing engine and back up through the stack, flow-controlled,
> reassembled, and submitted to the receiving socket. Also, ACK packets
> have to be sent back to the sender through the same tortuous path.
My notion of a "properly designed" kernel is one that has a shortcircuit
path for local TCP connections, to avoid precisely that overhead. Not
all do ... but any kernel wherein attention has been paid to X Windows
performance (to mention just one important case) does.
For example, doing a COPY OUT of about 10MB of data, I get numbers
like this:
$ time psql -h localhost -c "copy foo to stdout" regression >/dev/null
real 0m29.05s
user 0m1.40s
sys 0m0.12s
$ time psql -c "copy foo to stdout" regression >/dev/null
real 0m28.97s
user 0m1.39s
sys 0m0.10s
which is the same to within experimental error, considering there are
background daemons &etc on this machine (an HP-PA box running HPUX
10.20).
Of course, since the kernel is certainly capable of net socket
throughput well in excess of 0.3 megabytes/sec on this machine, this
example really just proves Doug's other point: the difference between a
Unix socket and a TCP socket is unlikely to be important for Postgres
purposes, because it'll be swamped by other factors.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Doug McNaught <doug@wireboard.com> writes: > > For a localhost TCP socket, a write() has to be sent down the network > > stack and (possibly) split into packets, which are then sent through > > the routing engine and back up through the stack, flow-controlled, > > reassembled, and submitted to the receiving socket. Also, ACK packets > > have to be sent back to the sender through the same tortuous path. > > My notion of a "properly designed" kernel is one that has a shortcircuit > path for local TCP connections, to avoid precisely that overhead. Not > all do ... but any kernel wherein attention has been paid to X Windows > performance (to mention just one important case) does. Hmmm. I would take issue with your notion of "properly designed"--one might instead use the phrase "insanely bloated with special cases". ;) X can, and should, use Unix sockets and/or shared memory for speed when connecting to the local display. I don't intend to start a flamewar--I just think "properly designed" is a matter of philosophy. > Of course, since the kernel is certainly capable of net socket > throughput well in excess of 0.3 megabytes/sec on this machine, this > example really just proves Doug's other point: the difference between a > Unix socket and a TCP socket is unlikely to be important for Postgres > purposes, because it'll be swamped by other factors. Yeah, I think that was my main point, though I didn't really emphasize it very well. Thanks for the followup. -Doug