On 8/13/04 5:22 PM, Perrin Harkins wrote: > On Fri, 2004-08-13 at 17:05, John Siracusa wrote: >> Even without threads, wouldn't you rather have each apache child pulling >> connections from a shared, server-wide pool rather than holding onto at >> least one connection a piece whether they need it or not? > > Sure. Can you figure out a way to do it?
Probably not in Perl 5 and apache 1.x, but I hope Perl 6, apache 2, and mod_(perl6|parrot) will be flexible enough... > You actually have a site where you can run more apache children than > database connections? I have never seen such a beast. Maybe your database is just too beefy? :) I've worked on sites that would routinely bump into a database connection limit of ~200 during traffic spikes. (And yes, of course static content was served elsewhere :) >> Maybe that'd lead to too much contention, I don't know, but I assumed >> something like that was a long-term mod_perl2/apache2/perl6 goal. Or maybe >> it's just a personal fantasy... :) > > Perl6 would presumably mean mod_perl 3. ...or mod_parrot or something, especially if this Parrot DBI-like-core thing takes off (I forget the name they're using) > Anyway, the pooling thing is mostly driven by how much Java people hype it. > The usefulness of pooling is pretty limited for a site that actually uses > database connections on every request. I've worked on sites that use a "session" (MySQL) database connection on every request, but don't use a "main" (Postgres) database connection nearly that often. If that main database is shared by several sites/apps, it can become the bottleneck. Maybe read-only replication would help, but it still seems wasteful. -John -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
