Re: DBI persistence problem

2004-12-02 Thread Rob Mueller
5. We easily reach 1024 webserver processes, apache 1.3. This really sounds like a lot more httpd mod_perl processes than you should need, even on a heavily loaded system. Are you using a light frontend proxy/accelerator? http://perl.apache.org/docs/1.0/guide/strategy.html If not, you definite

Re: DBI persistence problem

2004-12-02 Thread Perrin Harkins
On Wed, 2004-12-01 at 17:48 -0600, Richard N. Fogle wrote: > We were thinking of using SQLRelay as a connection pool and > concentrator, thinking it would be less expensive to wrap a > connection/cursor through a unix socket into a pool vs. throwing all > this at a remote server. Does that sound o

Re: DBI persistence problem

2004-12-01 Thread Richard N. Fogle
Malcom, Thank you for your response..  It does sound like a possibility that the script isn't all the way into completion as we have query->process result->query->process result->query->disconnect (figuratively) scripts.  We were thinking of using SQLRelay as a connection pool and concentrator

Re: DBI persistence problem

2004-12-01 Thread Malcolm J Harwood
On Wednesday 1 December 2004 08:26 pm, Richard N. Fogle wrote: > 1. We disabled Apache::DBI - the server can generate thousands of > queries per second and this feature literally made the CPU catch fire. Odd. Normally (in my limited experience) it has the reverse effect as you aren't creating a

Re: DBI persistence problem

2004-12-01 Thread Richard N. Fogle
Malcom and Perrin, Thank you for your quick replies! 1.  We disabled Apache::DBI - the server can generate thousands of queries per second and this feature literally made the CPU catch fire. 2.  Understood about placing the connect strings in startup.PL.  That's why we wrote the list first :

Re: DBI persistence problem

2004-12-01 Thread Perrin Harkins
On Wed, 2004-12-01 at 19:00 -0600, Richard N. Fogle wrote: > The problem we're having is each time the CGI is called it seems to > make a persistent connection to the database despite the fact that we > have a $dbh->disconnect(); at the end of the code. Are you using Apache::DBI anywhere? Make su

Re: DBI persistence problem

2004-12-01 Thread Malcolm J Harwood
On Wednesday 1 December 2004 08:00 pm, Richard N. Fogle wrote: > Basically, we have one MySQL cluster setup for reads and the other > cluster for writes - the reads cluster alternates between master and > slave. This works fine. The problem we're having is each time the CGI > is called it seems