DB - persistent connection?

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • Derek Fountain
    #1

    DB - persistent connection?

    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.derekfounta in.org/">Derek Fountain</a>
    Tags: None
    • Michael Fesser
      #2
      Re: DB - persistent connection?

      .oO(Derek Fountain)
      [color=blue]
      >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?[/color]

      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.
      [color=blue]
      >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.[/color]

      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

        Comment

        • Alvaro G Vicario
          #3
          Re: DB - persistent connection?

          *** Derek Fountain wrote/escribió (Thu, 24 Feb 2005 10:26:58 +0800):[color=blue]
          > 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?[/color]

          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
          --

            Comment

            • Andy Hassall
              #4
              Re: DB - persistent connection?

              On Thu, 24 Feb 2005 10:26:58 +0800, Derek Fountain <nospam@example .com> wrote:
              [color=blue]
              >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?[/color]

              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;
              MaxRequestsPerC hild 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 / <andy@andyh.co. uk> / <http://www.andyh.co.uk >
              <http://www.andyhsoftwa re.co.uk/space> Space: disk usage analysis tool

                Comment

                Previous template Next
                Working...