On Thu, Oct 26, 2000 at 08:47:20PM +0100, Matt Sergeant wrote:
> On Tue, 24 Oct 2000, Jeff Horn wrote:
>
> > However, I am also aware of a _major_ ISP that implements their email
> > system using a _major_ RDBMS that has had problems that are best
> > solved via connection pooling. Essentially, the time it takes them to
> > search through all the cached connections is nearly as long as the
> > time it is taking to read/write to the database. Although, I'm not
> > implementing email as this ISP is, I think that scalability in my case
> > may definitely run into similar roadblocks.
> >
> > I am interested in hearing from anyone that has tried to implement
> > true connection pooling either within Apache or as an external
> > process. I'm particularly interested in hearing about implementations
> > that could be made to work or are done using Perl and DBI/DBD. I am
> > mostly interested in things that are Open Source or licensed like Perl
> > itself.
>
> Having just returned from ApacheCon, I can honestly recommend looking at
> mod_backhand to simply have a few servers that run the DBI pool, and have
> database intensive requests go to those servers. It is a *very* cool
> solution to just these sorts of scalability problems.
To redirect incoming url's that require database work to mod_perl 'heavy'
servers? Just like a smarter and more dynamic mod_rewrite? Yes?
Or, here's an odd thought that just crossed my mind...
You could have a set of apache servers that are 'pure' DBI proxy servers.
That is, they POST requests containing SQL (for prepare_cached) plus
bind parameter values and return responses containing the results.
Basically I'm proposing that apache be used as an alternative framework for
DBI::ProxyServer. Almost all the marshaling code and higher level logic
is already in DBI::ProxyServer and DBD::Proxy. Shouldn't be too hard to do
and you'd gain in all sorts of ways.
Anyone fancy having a go? Let me know so we can discuss it in more detail.
Tim.
