By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,033 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

DB - persistent connection?

P: n/a
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>
Jul 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
.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
Jul 17 '05 #2

P: n/a
*** 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
--
Jul 17 '05 #3

P: n/a
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
Jul 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.