Re: Concurrency testing

David E. Wheeler wrote:
> On Oct 7, 2009, at 5:18 PM, Jeff Janes wrote:
>
>> I'd much rather live without Test::More and use DBD::Pg, then have
>> Test::More but need to open pipes to psql to talk to the database,
>> rather than using DBI to do it. But I guess we would need to worry
>> about whether we can make DBD::Pg work with the installation being
>> tested, rather than finding some other install.
>
> The test architecture depends on Perl, but not on the DBI. I don't
> think that Andrew wants to add any dependencies. Therefore we'd need
> to use file handles. That's not to say that we couldn't write a nice
> little interface for it such that the implementation could later change.

Well, that's true of the buildfarm. And there are reasons I don't want
to use DBI for the buildfarm, mainly to do with its intended role in
simulating what a human would do by hand.

What we do for the core testing framework is a different question.
Nevertheless, a requirement for DBI and DBD::Pg would be a significant
escalation of testing prerequisites. Test::More is comparatively modest
requirement, and is fairly universal where Perl is installed. And since
we'd just be using it to drive psql, we wouldn't be having to decide if
a problem we saw was due to a problem in Postgres or a problem in DBD::Pg.

If we want something to drive a huge number of clients, I suspect
neither of these is a good way to go, and something more custom built
would be required. Last time I built something to drive a huge client
load (many thousands of simultaneous connections to a web app) I did it
in highly threaded Java using HttpUnit from a number of separate client
machines. You wouldn't believe what that managed to do to MySQL on the
backend ;-)

cheers

andrew