From hartzell at alerce.com  Thu Nov  1 11:45:45 2012
From: hartzell at alerce.com (George Hartzell)
Date: Thu, 1 Nov 2012 11:45:45 -0700
Subject: [sf-perl] [meeting] 'CPAN In The Sky With Diamonds'
	tomorrow	evening
In-Reply-To: <0A80DC76-AAB0-4B4F-9C26-D1708F269298@imaginative-software.com>
References: <CAHrynWB8FRxSR-+vxdK2nD2cRVgRrvR+3wVT8=axC-PY8GhuDA@mail.gmail.com>
	<15F23303-F6F7-4EC0-9C7E-FFD612193727@imaginative-software.com>
	<0A80DC76-AAB0-4B4F-9C26-D1708F269298@imaginative-software.com>
Message-ID: <20626.50009.944833.543977@gargle.gargle.HOWL>

Jeffrey Thalhammer writes:
 > [...]
 > By the way, what is your favorite tool for load & performance
 > testing a web app? 

Was it actually the web-ish part of the app that blew up?

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.

g.

From jeff at imaginative-software.com  Thu Nov  1 13:02:26 2012
From: jeff at imaginative-software.com (Jeffrey Thalhammer)
Date: Thu, 1 Nov 2012 13:02:26 -0700
Subject: [sf-perl] [meeting] 'CPAN In The Sky With Diamonds' tomorrow
	evening
In-Reply-To: <20626.50009.944833.543977@gargle.gargle.HOWL>
References: <CAHrynWB8FRxSR-+vxdK2nD2cRVgRrvR+3wVT8=axC-PY8GhuDA@mail.gmail.com>
	<15F23303-F6F7-4EC0-9C7E-FFD612193727@imaginative-software.com>
	<0A80DC76-AAB0-4B4F-9C26-D1708F269298@imaginative-software.com>
	<20626.50009.944833.543977@gargle.gargle.HOWL>
Message-ID: <240216A9-76FA-4272-B5C6-CE8C7403570D@imaginative-software.com>


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.  What I was looking for was a framework for doing that activity simultaneously (i.e. as multiple concurrent users) and tracking performance along the way.  I'm sure I can do that with the right combination of Test::* modules and forking.  I just thought there might be something ready-made.

-Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/sanfrancisco-pm/attachments/20121101/bc8244b9/attachment.html>

From fred at redhotpenguin.com  Thu Nov  1 15:16:50 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Thu, 1 Nov 2012 15:16:50 -0700
Subject: [sf-perl] [meeting] 'CPAN In The Sky With Diamonds' tomorrow
	evening
In-Reply-To: <240216A9-76FA-4272-B5C6-CE8C7403570D@imaginative-software.com>
References: <CAHrynWB8FRxSR-+vxdK2nD2cRVgRrvR+3wVT8=axC-PY8GhuDA@mail.gmail.com>
	<15F23303-F6F7-4EC0-9C7E-FFD612193727@imaginative-software.com>
	<0A80DC76-AAB0-4B4F-9C26-D1708F269298@imaginative-software.com>
	<20626.50009.944833.543977@gargle.gargle.HOWL>
	<240216A9-76FA-4272-B5C6-CE8C7403570D@imaginative-software.com>
Message-ID: <CAHrynWBs7hKA9-VbXsGM+Bz3WLaBQ-L31-YWAFXTV2_qOQMSJw@mail.gmail.com>

On Thu, Nov 1, 2012 at 1:02 PM, Jeffrey Thalhammer
<jeff at imaginative-software.com> wrote:
> I just
> thought there might be something ready-made.

Try ab (apache bench), ships with Apache. Not an end all load tester
but will get you a lot farther down the road right now pretty easily.

From hartzell at alerce.com  Thu Nov  1 15:29:03 2012
From: hartzell at alerce.com (George Hartzell)
Date: Thu, 1 Nov 2012 15:29:03 -0700
Subject: [sf-perl] [meeting] 'CPAN In The Sky With Diamonds' tomorrow
	evening
In-Reply-To: <240216A9-76FA-4272-B5C6-CE8C7403570D@imaginative-software.com>
References: <CAHrynWB8FRxSR-+vxdK2nD2cRVgRrvR+3wVT8=axC-PY8GhuDA@mail.gmail.com>
	<15F23303-F6F7-4EC0-9C7E-FFD612193727@imaginative-software.com>
	<0A80DC76-AAB0-4B4F-9C26-D1708F269298@imaginative-software.com>
	<20626.50009.944833.543977@gargle.gargle.HOWL>
	<240216A9-76FA-4272-B5C6-CE8C7403570D@imaginative-software.com>
Message-ID: <20626.63407.981424.920052@gargle.gargle.HOWL>

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.

From fred at redhotpenguin.com  Thu Nov  1 15:42:37 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Thu, 1 Nov 2012 15:42:37 -0700
Subject: [sf-perl] [meeting] 'CPAN In The Sky With Diamonds' tomorrow
	evening
In-Reply-To: <20626.63407.981424.920052@gargle.gargle.HOWL>
References: <CAHrynWB8FRxSR-+vxdK2nD2cRVgRrvR+3wVT8=axC-PY8GhuDA@mail.gmail.com>
	<15F23303-F6F7-4EC0-9C7E-FFD612193727@imaginative-software.com>
	<0A80DC76-AAB0-4B4F-9C26-D1708F269298@imaginative-software.com>
	<20626.50009.944833.543977@gargle.gargle.HOWL>
	<240216A9-76FA-4272-B5C6-CE8C7403570D@imaginative-software.com>
	<20626.63407.981424.920052@gargle.gargle.HOWL>
Message-ID: <CAHrynWAi_tbB2LMozvSZRyTZ1QGMNhxT5K6Ove9eGMef8_M9gA@mail.gmail.com>

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.

From fred at redhotpenguin.com  Wed Nov  7 17:22:43 2012
From: fred at redhotpenguin.com (Fred Moyer)
Date: Wed, 7 Nov 2012 17:22:43 -0800
Subject: [sf-perl] [meeting] Fun with Perl, Redis,
	and AnyEvent with Jeremy Zawodny from craigslist
Message-ID: <CAHrynWDZGgr4iX+eGRJwf7c0sOp3XN7SRvDgWkRDg69-PndXug@mail.gmail.com>

Our next meeting is Tuesday November 27th at 7pm, please rsvp at the
meetup link below if you plan to attend.

craigslist is a Perl shop that makes increasing use of Redis in our
infrastructure. This presentation will cover our use cases at high
level, learnings from our long-running production Redis clusters, and
discuss motivation for creating AnyEvent::Redis::Federated. Little
prior experience with either Redis or AnyEvent is necessary for this
presentation.

http://www.meetup.com/San-Francisco-Perl-Mongers/events/86790152/

Jeremy Zawodny on LinkedIn - http://www.linkedin.com/in/jzawodn