Re: Strange result: UNIX vs. TCP/IP sockets - Mailing list pgsql-performance

http://grotto11.com/blog/slash.html?+1039831658

Summary: IE and IIS cheat at TCP level by leaving out various SYN and ACK
packets, thereby making IE requests from IIS servers blazingly fast, and
making IE requests to non-IIS servers infuriatingly slow.

But since this only relates to making and breaking TCP connections, I don't
think this is relevant for a larger query time. It's probably normal for a TCP
connection to be slightly slower than a unix socket, but I don't think that's
wat Andrew is experiencing.

On 2003-07-04 14:35:18 -0300, The Hermit Hacker wrote:
>
> 'K, this is based on "old information", I don't know if Sun changed it
> 'yet again' ... but, when I was working at the University, one of our IT
> directors gave me a report that deal with something Sun did (god, I'm so
> detailed  here, eh?) to "mimic" how Microsoft broke the TCP/IP protocol
> ... the report was in relation to Web services, and how the change
> actually made Sun/Solaris appear to be slower then Microsoft ...
>
> And Sun made this the 'default' setting, but it was disablable in
> /etc/systems ...
>
> Sorry for being so vague, but if I recall correctly, it had something to
> do with adding an extra ACK to each packet ... maybe even as vague as the
> above is, it will jar a memory for someone else?
>
>
> On Fri, 4 Jul 2003, Andrew Sullivan wrote:
>
> > Hi all,
> >
> > We're run into a rather odd problem here, and we're puzzling out
> > what's going on.  But while we do, I thought I'd see if anyone else
> > has anything similar to report.
> >
> > This is for 7.2.4 on Solaris 8.
> >
> > We have a query for which EXPLAIN ANALYSE on a local psql connection
> > always returns a time of between about 325 msec and 850 msec
> > (depending on other load, whether the result is in cache, &c. -- this
> > is an aggregates query involving min() and count()).
> >
> > If I connect using -h 127.0.0.1, however, I can _sometimes_ get the
> > query to take as long as 1200 msec.  The effect is sporadic (of
> > course.  If it were totally predictable, the computing gods wouldn't
> > be having any fun with me), but it is certainly there off and on.
> > (We discovered it because our application is regularly reporting
> > times on this query roughly twice as long as I was able to get with
> > psql, until I connected via TCP/IP.)
> >
> > I'll have more to report as we investigate further -- at the moment,
> > this has cropped up on a production system, and so we're trying to
> > reproduce it in our test environment.  Naturally, we're looking at
> > the TCP/IP stack configuration, among other stuff.  In the meantime,
> > however, I wondered if anyone knows which bits I ought to be prodding
> > at to look for sub-optimal libraries, &c.; or whether anyone else has
> > run into similar problems on Solaris or elsewhere.
> >
> > A
> >
> > --
> > ----
> > Andrew Sullivan                         204-4141 Yonge Street
> > Liberty RMS                           Toronto, Ontario Canada
> > <andrew@libertyrms.info>                              M2P 2A8
> >                                          +1 416 646 3304 x110
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 8: explain analyze is your friend
> >
>
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Vincent van Leeuwen
Media Design - http://www.mediadesign.nl/