DB - persistent connection?

[Derek Fountain]

For a low-ish traffic website that is doing the simple "build pages from
HTML templates and info in a database" kind of thing, do the wise folks in
this newsgroup advocate connecting and disconnecting from the DB with each
query, or maintaining a persistent connection in the session?

I guess my application could work either way, and I've gravitated towards
the connect-query-disconnect method, but not for any really good reason. It
struck me as simpler to stick with the stateless way of doing it. The only
obvious drawback I can see is the performance penalty, which I guess could
be large if the website gets busy.

What do other people think? Is there an obvious best practise on the merits,
or is it down to the application and developer?

--
The email address used to post is a spam pit. Contact me at
http://www.derekfountain.org : <a
href="http://www.derekfountain.org/">Derek Fountain</a>

[Michael Fesser]

.oO(Derek Fountain)

For a low-ish traffic website that is doing the simple "build pages from
HTML templates and info in a database" kind of thing, do the wise folks in
this newsgroup advocate connecting and disconnecting from the DB with each
query, or maintaining a persistent connection in the session?
I open the connection when I create my database object and close it when
the object gets destroyed, usually at the end of the script. So it's
neither per-query nor real persistent, but simply per-page/per-request.
I guess my application could work either way, and I've gravitated towards
the connect-query-disconnect method, but not for any really good reason.

I wouldn't do that, and I wouldn't use real persistent connections
either, because it may waste server resources on a shared host. If you
have your own server then of course you can do whatever you want.

Micha

[Alvaro G Vicario]

*** Derek Fountain wrote/escribió (Thu, 24 Feb 2005 10:26:58 +0800):

For a low-ish traffic website that is doing the simple "build pages from
HTML templates and info in a database" kind of thing, do the wise folks in
this newsgroup advocate connecting and disconnecting from the DB with each
query, or maintaining a persistent connection in the session?

I've seen low traffic sites go down for using persistent connections. You
can easily reach a limit of 100 connections used with hardly any visitor.
--
-- Álvaro G. Vicario - Burgos, Spain
-- Thank you for not e-mailing me your questions
--

[Andy Hassall]

On Thu, 24 Feb 2005 10:26:58 +0800, Derek Fountain <no****@example.com> wrote:

For a low-ish traffic website that is doing the simple "build pages from
HTML templates and info in a database" kind of thing, do the wise folks in
this newsgroup advocate connecting and disconnecting from the DB with each
query, or maintaining a persistent connection in the session?

I guess my application could work either way, and I've gravitated towards
the connect-query-disconnect method, but not for any really good reason. It
struck me as simpler to stick with the stateless way of doing it. The only
obvious drawback I can see is the performance penalty, which I guess could
be large if the website gets busy.

What do other people think? Is there an obvious best practise on the merits,
or is it down to the application and developer?

It Depends (tm) on how many distinct connections you use, where a connection
is defined by both the database and the username.

If all your applications on the server use a small set of user credentials
against a small set or one database, then persistent connections are great,
particularly for databases where connection is not particularly cheap (e.g.
Oracle).

If you access more than a small number of distinct username/database
combinations, persistent connections can be disastrous, as over time each
webserver child process will each build up a pool of connections to each of the
username/database combinations and hold them open.

I consider the fact that PHP's persistent database connection infrastructure
doesn't include a "disconnect after X seconds" feature a fairly nasty flaw -
surely you'd want your pool of connections to form a common working set of
connections, rather than holding open connections for eternity. This can
probably be mitigated by webservers' methods of recycling child processes;
MaxRequestsPerChild in Apache, or the equivalent methods of recycling worker
processes in IIS6, but this seems to be the wrong level to do this.

--
Andy Hassall / <an**@andyh.co.uk> / <http://www.andyh.co.uk>
<http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool