Обсуждение: Number of connections
List,
I cannot tell from the documentation if pg_pconnect() or pg_connect()
are really different in how the connection pool is managed. Does anyone
know if that is the case? Seems that using pg_pconnect would dictate "use a
pooled connection" and pg_connect is "use a pooled connection, or make a new
one". On "live" apps which is better to use, seems pg_pconnect. Thoughts?
David Busby
Systems Engineer
busby@pnts.com
On Sat, 17 May 2003, David Busby wrote: > List, > I cannot tell from the documentation if pg_pconnect() or pg_connect() > are really different in how the connection pool is managed. Does anyone > know if that is the case? Seems that using pg_pconnect would dictate "use a > pooled connection" and pg_connect is "use a pooled connection, or make a new > one". On "live" apps which is better to use, seems pg_pconnect. Thoughts? This is a far more complex subject than it may at first appear. The first and most important point is that PHP doesn't "pool" connections when using persistant connections. what happens is that each apache child preocess holds a connection open after a pconnect has been used. this means that using the default apache configuration option of 150 max children, and the postgresql default of 32, that after a little bit of load is applied, your whole web site comes crashing with errors about no more backend connections available. I.e. using pconnect without understand the implications, and configuring your web site accordingly, is dangerous. pconnects in PHP are like tiny ints in mysql, I consider them to almost be a misfeature, in that they are so often used by folks who don't know what they're getting themselves into. pconnects don't save much time. My testing showed them to be 1,000 times faster than regular connects. Unfortunately, since regular connects run in about 1 mS, having persistant connects run at 1 uS doesn't really help. I.e. the average PHP page takes 10 to 100 mS to run, so chopping off <1 mS from the connect speed is pretty much noise for most folks. Another issue is that if you use pconnect to two different databases in the same cluster in a PHP script, you now have TWO persistant connections open at the same. Open to three databases, three persistant connections. IF you want to use pconnects, then you need to do some system planning and configuration. If you are running multiple front end apache servers, they need to be configured so that you have fewer connects open than the max that postgresql can handle at any given time. So, set max children lower in apache (20 to 50 or so) and multiply the max number of different connects in each script, times the number of apache servers, add a 10 or 20 for overhead, and set the postgresql max connects to that. Otherwise, your site will have issues with connecting. And that would make it WAY slower than just using plain old connect.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, David Busby wrote: <snip> > one". On "live" apps which is better to use, seems pg_pconnect. Thoughts? > I prefer pg_pconnect due to its faster reconnect times - you may use a profiler to validate the effects for your application (e.g. http://www.adepteo.net/profiler/) HTH Phil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE+x4m0QogH4WkR2CwRAtdeAJ9MfXP0zoh5GE8JB7tMzFVt3Kq/NQCdFHZV Z05VXv/qYlwHzzHl4NDRZ6o= =fb5o -----END PGP SIGNATURE-----
A related mail I tried to post on the list yesterday but that I got back.... when inserting a record in a PHP script, I sometimes use the currval function on the corresponding sequence to get the id of the row inserted. Maybe a stupid question, but I wondered if when using persisten connection, I could be sure there would be no problem. From the doc, currval "Returns the value most recently obtained by nextval for this sequence in the current server process." Can you confirm me several script using the same persistent connection in parallel are in separate server processes? Thanks. Raph On Sat, May 17, 2003 at 11:53:44AM -0700, David Busby wrote: > List, > I cannot tell from the documentation if pg_pconnect() or pg_connect() > are really different in how the connection pool is managed. Does anyone > know if that is the case? Seems that using pg_pconnect would dictate "use a > pooled connection" and pg_connect is "use a pooled connection, or make a new > one". On "live" apps which is better to use, seems pg_pconnect. Thoughts? > > David Busby > Systems Engineer > busby@pnts.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
> Maybe a stupid question, but I wondered if when using persisten > connection, I could be sure there would be no problem. From the doc, > currval "Returns the value most recently obtained by nextval for this > sequence in the current server process." > > Can you confirm me several script using the same persistent connection > in parallel are in separate server processes? PHP will execute 'begin; rollback;' to your connection before passing it to another PHP process, guaranteeing that unclosed transactions won't leak. Chris
Actually, you can't be sure. It is quite possible to build a system in PHP that will behave in unwanted ways if you leave transactions open across accesses. Apache is stateless, with a thing layer of semi-statefullness layered on top like butter. This is the keep alive system, which is a stock part of the http 1.1 spec. What happens is that when a user accesses a web page, a certain apache backend gets associated to it for a short period of time. The problem with keep alive is that apache has a short attention span, since the default timeout for keep alives is 15 seconds. Let's say user A opens a web page with a form, and edits it for 3 minutes. His keep alive connection is gone. While it is still very likely that his next request will be serviced by the same child as the last time, there is NOT guarantee. Even if the user does make the changes before the timeout, or you crank up the timeout to something huge like 30 minutes, they still aren't guaranteed to get their own child process back, as if someone requested access and all the other children are now tied up in keep alives or active requests, the apache server throws the pid of all the kept alive and waiting requests and randomly grabs one to service the request. Poof, keep alive gone, not the same connection. So, you can't count on always getting your old transaction back. What you can do is rollback at the beginning of each script to make sure you're in "clean space" transactionally. For a read only type setup, where you're tossing a cursor around, you might be able to check for the existence of one, but I don't know how. On Sun, 18 May 2003, Raphael Bauduin wrote: > A related mail I tried to post on the list yesterday but that I got > back.... > > when inserting a record in a PHP script, I sometimes use the currval > function on the corresponding sequence to get the id of the row > inserted. > > Maybe a stupid question, but I wondered if when using persisten > connection, I could be sure there would be no problem. From the doc, > currval "Returns the value most recently obtained by nextval for this > sequence in the current server process." > > Can you confirm me several script using the same persistent connection > in parallel are in separate server processes? > > Thanks. > > Raph > > > > On Sat, May 17, 2003 at 11:53:44AM -0700, David Busby wrote: > > List, > > I cannot tell from the documentation if pg_pconnect() or pg_connect() > > are really different in how the connection pool is managed. Does anyone > > know if that is the case? Seems that using pg_pconnect would dictate "use a > > pooled connection" and pg_connect is "use a pooled connection, or make a new > > one". On "live" apps which is better to use, seems pg_pconnect. Thoughts? > > > > David Busby > > Systems Engineer > > busby@pnts.com > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
On Fri, 23 May 2003, Christopher Kings-Lynne wrote: > > Maybe a stupid question, but I wondered if when using persisten > > connection, I could be sure there would be no problem. From the doc, > > currval "Returns the value most recently obtained by nextval for this > > sequence in the current server process." > > > > Can you confirm me several script using the same persistent connection > > in parallel are in separate server processes? > > PHP will execute 'begin; rollback;' to your connection before passing it to > another PHP process, guaranteeing that unclosed transactions won't leak. Didn't it used to not do that? I remember posts about people having issues with transaction bleedover back in the day.
At 17:45 23.05.2003, scott.marlowe said:
--------------------[snip]--------------------
>...
>The problem with keep alive is that apache has a short attention span,
>since the default timeout for keep alives is 15 seconds. Let's say user A
>opens a web page with a form, and edits it for 3 minutes. His keep alive
>connection is gone. While it is still very likely that his next request
>will be serviced by the same child as the last time, there is NOT
>guarantee.
--------------------[snip]--------------------
I've read in another thread (either here, or in php-general) that PHP
clears out any transactions that might be open when you pg_connect() or
ph_pconnect(), by issuing "begin;rollback;".
If this is the case this would mean you simply CANNOT have transactions
open across multiple requests.
Which is a good thing IMHO. Just think of the mess that would be created if
client A opens a transaction, client B (using the same child process,
pg_pconnect()ing to the same database) runs a totally different set of
instructions and commits the transaction. A's "transaction" would be
partially committed by B...
Transactions are designed to be atomic operations, and I strongly believe
they should be treated exactly this way - begin, do your stuff, commit or
rollback. In one request. Anyway, pending transactions may lock rows or
tables, and may keep other parts of an application from running at all.
Just my 2c worth...
--
>O Ernest E. Vogelsinger
(\) ICQ #13394035
^ http://www.vogelsinger.at/
> Didn't it used to not do that? I remember posts about people having > issues with transaction bleedover back in the day. Yeah, but it's been doing it for a while now. It think in 7.3 they could probably even trim it down to just ROLLBACK? Chris