You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Michael Teter <mi...@yahoo.com> on 2002/12/23 18:56:12 UTC
Database Pooling
Howdy.
I'm very new to mod_perl, so if this question makes no sense, say so :)
My understanding is that database access via mod_perl is pooled, but only
per-httpd. So if I had 10 active httpds running, I would have 10x(number of
connections per pool).
In contrast, my Java/JSP/Servlet solution has a single pool. I'm trying to
evaluate mod_perl to use instead of my current Java-based solution, but the
potentially high number of database connections scares me.
Do production, public mod_perl-based sites have 10s or 100s of database
connections open?
Any direction will be appreciated.
Michael
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Database Pooling
Posted by Gunther Birznieks <gu...@extropia.com>.
If I recall correctly, Jeffrey Baker (author of Apache::Session) wrote
an extremely lucid and well thought out argument about why the way
mod_perl pools connections is just as well as Java in reality.
Try searching for his name in the mod_perl list archives.. I think he
wrote this over a year ago, but less than 2 years ago.
Later,
Gunther
Michael Teter wrote:
> Howdy.
>
> I'm very new to mod_perl, so if this question makes no sense, say so :)
>
> My understanding is that database access via mod_perl is pooled, but only
> per-httpd. So if I had 10 active httpds running, I would have 10x(number of
> connections per pool).
>
> In contrast, my Java/JSP/Servlet solution has a single pool. I'm trying to
> evaluate mod_perl to use instead of my current Java-based solution, but the
> potentially high number of database connections scares me.
>
> Do production, public mod_perl-based sites have 10s or 100s of database
> connections open?
>
> Any direction will be appreciated.
>
> Michael
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
>
Re: Database Pooling
Posted by pe...@elem.com.
> My understanding is that database access via mod_perl is pooled, but
> only per-httpd. So if I had 10 active httpds running, I would have
> 10x(number of connections per pool).
The number of connection per "pool" (it's really just a cache) is normally
one, so you have one per process. You would only have more than one if
you are using multiple databases or multiple logins top the same database,
which you should avoid if possible.
> In contrast, my Java/JSP/Servlet solution has a single pool. I'm
> trying to evaluate mod_perl to use instead of my current Java-based
> solution, but the potentially high number of database connections
> scares me.
If you have 10 requests that need to use the database, they will be using
10 connections no matter what technology you run on.
If you run the suggested front-end proxy setup to serve static content,
then only request that actually need a database connection will go to
mod_perl.
- Perrin
Re: Database Pooling
Posted by do...@idealx.com.
> Sounds like you should have some more code in your finally
> blocks. :)
Well I don't quite like having to do that everywhere, especially in
code I did not write. In Perl I only need one of them using some
AUTOLOAD trickery :-).
--
Dominique QUATRAVAUX Ingénieur développeur senior
01 44 42 00 35 IDEALX
Re: Database Pooling
Posted by Kenny Smith <ke...@journalscape.com>.
> Sure. And beware of connections that are returned to the pool without
> being rollbacked, too - the app then deadlocks itself because it holds
> locks in the database and doesn't know it does. I get bitten by this
> under JDBC every so often, when an exception is thrown at the wrong
> time.
Sounds like you should have some more code in your finally blocks. :)
KS
Re: Database Pooling
Posted by do...@idealx.com.
>
> Well, it's going to be a pretty strange environment that doesn't have a
> database connection in every process.
Sure. And beware of connections that are returned to the pool without
being rollbacked, too - the app then deadlocks itself because it holds
locks in the database and doesn't know it does. I get bitten by this
under JDBC every so often, when an exception is thrown at the wrong
time.
>From the app perspective, I tend to prefer viewing database
connections as singletons rather than pooled objects. This avoids lots
of problems like the two above, and enables fancy extensions. For
example I can simulate nested transactions even on databases that do
not support them: I can say "If a transaction is open in the (unique)
database connection we have, don't start a new one and just up the
(app-internal) nesting counter".
--
Dominique QUATRAVAUX Ingénieur développeur senior
01 44 42 00 35 IDEALX
Re: Database Pooling
Posted by Kenny Smith <ke...@journalscape.com>.
> Not necessarily, that would be your MAXIMUM number of simultaneous
> connections, unless you connect to all the datababases when a children
> is spawn (which would be pretty dull methinks, I prefer lazy
> algorithms).
Well, it's going to be a pretty strange environment that doesn't have a
database connection in every process. After a certain number of
requests, you can pretty much be assured that your database application
has been hit in every process and therefore every process has a
connection. Thinking of it as just the maximum is semantically correct,
but in reality, thinking of it as your common load is the best practice.
Kenny Smith
Re: Database Pooling
Posted by Stas Bekman <st...@stason.org>.
Jean-Michel Hiver wrote:
[...]
> * I _think_ that mod_perl 2 on Apache 2 might solve your problem since
> it's threaded (list, am I right here? I'm still working on mp1 for the
> most part)
Eventually, yes.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Database Pooling
Posted by Jean-Michel Hiver <jh...@mkdoc.com>.
> My understanding is that database access via mod_perl is pooled, but only
> per-httpd. So if I had 10 active httpds running, I would have 10x(number of
> connections per pool).
Not necessarily, that would be your MAXIMUM number of simultaneous
connections, unless you connect to all the datababases when a children
is spawn (which would be pretty dull methinks, I prefer lazy
algorithms).
> In contrast, my Java/JSP/Servlet solution has a single pool. I'm
> trying to evaluate mod_perl to use instead of my current Java-based
> solution, but the potentially high number of database connections
> scares me.
True, however there are many things you can do:
* The easy solution: increment your database maximum simultaneous
connections
* I _think_ that mod_perl 2 on Apache 2 might solve your problem since
it's threaded (list, am I right here? I'm still working on mp1 for the
most part)
* As a last resort, you can use SQL Relay [1] which looks like an ok
workaround
* Finally, your problem is only a problem if you're running lots of
different applications accessing lots of different databases with lots
of mod_perl processes :)
[1] http://sourceforge.net/projects/sqlrelay/
Cheers,
--
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver@mkdoc.com - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/
Re: Database Pooling
Posted by Christian Jaeger <ch...@ethlife.ethz.ch>.
At 9:56 Uhr -0800 23.12.2002, Michael Teter wrote:
>Do production, public mod_perl-based sites have 10s or 100s of database
>connections open?
Using mod_accel (better than mod_proxy) for a proxying setup you can
keep the number of mod_perl enabled httpd children low, saving both
memory and database connections. But at least with mysql you
shouldn't have any problems with hundreds of connections in any case.
Christian.