[Catalyst] Catalyst performance under load

[Yuval Kogman]

On Thu, Feb 09, 2006 at 11:36:31 -0000, Richard Jolly wrote:
>  > From: catalyst-bounces at lists.rawmode.org 
> > [mailto:catalyst-bounces at lists.rawmode.org] On Behalf Of Yuval Kogman
> > Sent: 09 February 2006 10:38
> > To: The elegant MVC web framework
> > Subject: Re: [Catalyst] Catalyst performance under load
> > 
> > On Thu, Feb 09, 2006 at 10:30:13 -0000, Richard Jolly wrote:
> > > Hi,
> > > 
> > > We've been using Catalyst for a project with much 
> > happiness. But now 
> > > we have some hostile management questions about performance 
> > under load.
> > > Basically its considered new, unproven technology good for 
> > 'prototyping'
> > > but quite probably inappropriate for production.
> > > 
> > > So I'm asking if there is any existing data for load/stress 
> > testing, 
> > > or anecdotal accounts of it being used for high 
> > availability/high load 
> > > sites. I've seen the wiki page listing sites using catalyst [ 
> > > http://dev.catalyst.perl.org/ ], but I fear none of these are big 
> > > enough to convince management.
> > 
> > I don't think there are any data sheets out there, but I 
> > don't really know.
> > 
> > Instead I will offer this advice:
> > 
> > I can almost guarantee that Catalyst will *NOT* be the 
> > overhead directly. It is much more likely that fetching the 
> > data from the database takes 90% of your time.
> > 
> > If you benchmark with that apache benchmark utility and the 
> > results are not satisfying enough you can try to employ 
> > aggressive caching of results at their most reusable level 
> > (if an object is used twice in two different pages, cache the 
> > object. If it's used in only one page, cache the template output).
> 
> The project is still new - we haven't even hooked it up to apache yet,
> just using the development server.
>  
> > Worst case scenario - change your ORM, or switch to plain DBI 
> > for a few select queries. This will allow you to do 
> > aggressive prefetching and to spend less time transforming 
> > and accessibalizing data.
> 
> Yep. No argument from me. Currenty DBIC is the ORM. 
> 
> > Remember that latency and load are almost orthogonal - most 
> > of the delay a low performance webapp might suffer from is 
> > not necessarily high load - IO waits account for a lot of 
> > time, typically.
> > 
> > > We have to make a case to an unsympathetic audience - 
> > please help us 
> > > gather evidence and arguments.
> > 
> > When in doubt, use mod_perl as an argument: Amazon, Yahoo 
> > (?), Etoys - they all use Perl at least to some extent, as do 
> > many other "serious" sites.
> 
> Its not perl or mod_perl that's under suspcision here - its Catalyst
> itself. Stablitiy and performance and considered 'unproven'. I used
> Mason for a long time. You could always stop this kind of argument by
> saying that Amazon used it. 

In that case based on my experience with a very "fast" site (no
dynamic content), on decent hardware Catalyst served ~200 requests
per second.

This means that Catalyst itself without the overhead seves even
more.

The overhead is present in two areas:

	Parsing the HTTP request

	Walking the dispatch tree, and invoking methods for dispatching

	probably ~20 method calls for various plugins to hook into, which are not
	strictly necessary calls

	Simple allocation of data structures (request contains headers,
	cookies, whatever)

Since perl can perform in the order of hundreds of thousands of
method call per second, and parsing the HTTP request has already
been optimized, what's left is optimizing the dispatcher.

In it's current state the dispatcher invokes several tree visitors
for every request (one for each inherited actoin (default, auto,
end), and one to search for the actual item, plus a linear regexp
search for every request that does not match to a single action)).

This is a lot of overhead in theory (in practice it is still
dwarfed by the view and model code 99% of the time), and no one has
done anything to optimize it because we're happy with it being
readable and clean.

If the need should arise I personally promise to add simple caching
to the dispatcher code that should make all common URIs (with
arguments) resolve in virtually O(1) time after the first request.
This should eliminate all the remaining overhead that is not
introduced by plugins.

-- 
 ()  Yuval Kogman <nothingmuch at woobling.org> 0xEBD27418  perl hacker &
 /\  kung foo master: uhm, no, I think I'll sit this one out..: neeyah!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060209/711b1181/attachment-0001.pgp