Barrie Slaymaker writes:
> Michael Peppler wrote:
> >
> > Based on preliminary tests I was able to use a 1 in 10 ratio of
> > database handles per httpd child processes, which, on a large site
> > would cut down on the number of connections that the database server
> > needs to handle.
>
> I'd be interested to see how this compares with Apache::DBI performance with
> MaxRequestsPerChild >= 100. I suspect it's negligable unless you're using
> a database like Oracle (with lots of connection establishment overhead) over
> a *slow* link.
The back-end is Sybase. The actual connect time isn't the issue here
(for me.) It's the sheer number of connections, and the potential
issue with the number of sockets in CLOSE_WAIT or TIME_WAIT state on
the database server. We're looking at a farm of 40 front-end servers,
each runnning ~150 modperl procs. If each of the modperl procs opens
one connection that's 6000 connections on the database side.
Sybase can handle this, but I'd rather use a lower number, hence the
pooling.
> I don't think there's any significant memory savings here, is there? Things
> you think might share physical memory probably don't after a SQL statement
> or two and some perl code gets run. Oracle certainly changes the RAM in
> their connection and cursor handles, for instance.
I'm not worried about RAM usage on the web servers.
Michael
--
Michael Peppler -||- Data Migrations Inc.
[EMAIL PROTECTED] -||- http://www.mbay.net/~mpeppler
Int. Sybase User Group -||- http://www.isug.com
Sybase on Linux mailing list: [EMAIL PROTECTED]
