On Mon, Jan 28, 2002 at 02:19:57PM -0500, Frank Bax wrote: > The connection will only be reused if the *same* apache child process > handles the request. IMHO, also if another apache child handles the request which also has a connection open to the same database using the same connection string. [ . . . ] > If your postgres database is on the same server as you webserver, there is > neglible gains for using pconnect over connect. Not exactly true, I think. A while ago I started a thread about using Unix sockets vs. TCP sockets because I had trouble getting Unix sockets to work on Solaris. It emerged from the discussion that the added overhead vis-a-vis local sockets of going through the TCP/IP stack was completely negligible compared to all the other stuff that is going on when making, or reusing, a (persistent or non-persistent) db connection. I should think that with a fast, non-saturated network, the fact that you then add a physical (e.g. Ethernet) layer to the scenario would not matter much either. I recently split webserver and db server here (basically to make administration less of a headache because I had Postgres servers running on 2 different boxes, for Intranet and Internet), and put the databases from the Postgres server running on the webserver (an old Dual PPro 200) onto a somewhat newer, 2nd box (Dual PII 400). It makes quite a difference, speed-wise, which would support my line of reasoning. I didn't try to measure this scientifically (or pseudo-scientifically, for that matter). Whether you get a performance gain from using pconnect over connect depends on whether you use simple queries (connection overhead is large compared to query execution time) or complex queries (connection overhead is small compared to query execution time). It has little to do, IMHO, with whether you go throug local sockets or TCP/IP sockets, or if your Postgres server is on the same physical machine as your webserver. Regards, Frank
