[sf-perl] [meeting] 'CPAN In The Sky With Diamonds' tomorrow evening

[George Hartzell]

Jeffrey Thalhammer writes:
 > 
 > On Nov 1, 2012, at 11:45 AM, George Hartzell wrote:
 > 
 > > Sounds to me that it was the back end.  If that's true and you've
 > > <armchair_quarterbacking> sliced things "right"
 > > </armchair_quarterbacking> then you can beat the day lights out of it
 > > without having to get any of the web ui involved.
 > > 
 > > My favorite tools in those cases have always been hand rolled and not
 > > particularly graceful, either doing something that I expect to be
 > > troublesome or actually replaying events from traces of real activity.
 > 
 > Right -- the failure was in the back end not the UI.  I know I can
 > use WWW::Mechanize to simulate a bunch of user activity. [...]

I was thinking it might be testable below the layer of anything WWW,
or possibly even http.

You'd like to set up a controlled scenario that duplicates the effects
of a large number [e.g. 4 ;)] of people simultaneously hitting the
site and see whether you get successful results, trace the db load,
etc....  Right?

I think that scraping HTML etc...  isn't relevant to the task at
hand.  And that you're going to end up running through a lot of stuff
that *should* be tested as an integration test but might be
confounding if you're trying to understand a scaling problem.

You presumably don't want TAP output for a bunch of individual steps
as you would from unit tests (though this might not be so true), you'd
like success or failure from an individual test "thread" and what
you're going to be evaluating are metrics from other sources (e.g. db
load, etc...).

If you wrote a bit of perl that emulated a work stream
(e.g. create an account, authenticate, create a repo, pull a distro)
you could use something like Parallel::ForkManager or
Parallel::Iterator to fire up $N$ of them at a time and watch your
load/logs/....

You might end up at the http level if your test scenario made a series
of calls via the REST interface, but I'm not sure whether or not
WWW::Mechanize etc... are the right tool for that.

Having said all of that, does anyone know of existing tool sets for
multiprocess stress testing of a general Perl based app?

g.