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

[Fred Moyer]

On Thu, Nov 1, 2012 at 3:29 PM, George Hartzell <hartzell at alerce.com> wrote:
> Jeffrey Thalhammer writes:
>  >
>  > On Nov 1, 2012, at 11:45 AM, George Hartzell wrote:
> 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?

WWW:Mech is too slow for load testing. About 5 years ago I wrote a
load tester using WWW::Curl and a thread enabled version of perl. It
took less time to write and test the tool than it did to deal with
planning, questions from management, etc.

Pros:
1) It was fast. There are some not so nice things about Perl threads,
but lack of speed is not one of them. Parallel::ForkManager is not as
fast.
2) It was fairly scalable. Each WWW::Curl object (read connection)
took about 10 megs of memory. Unfortunately Perl's ithread structures
don't allow you to share objects across threads, but 10 megs each is
fairly cheap.
3) It was programmatically easy to implement whatever changes we wanted.

Cons:
1) Perl threads still weren't 100% stable. The interpreter segfaulted
on about 1/4 runs. But the cool factor of using threads made up for
it.
2) It took a couple hours to get the initial thread handling loop
coded. There's an excellent tutorial by Sam Tregar which I think is
still on Perl.com
3) I can't remember for sure, but I don't think we could make https
requests at the time. And I think the major slowdowns in the system
were the ssl negotiation.