[Catalyst] Catalyst Performance issues
Nilson Santos Figueiredo Junior
acid06 at gmail.com
Sat Oct 7 18:25:27 CEST 2006
On 10/7/06, Perrin Harkins <perrin at elem.com> wrote:
> I haven't used DBIC, but I understand that the Class::C3 hit is mostly
> during startup. You don't want to profile that, since it doesn't affect
> the speed of your application. With mod_perl, you can skip that part by
> looking at the profile of a child process rather than the parent. I'm
> not sure how to do it with other server environments.
Actually, next::method calls are somewhat expensive when you're using
them for *everything* as it is on Catalyst / DBIC.
> That will be mostly useless unless you add the -r flag. The reason is
> that this profile is sorted by CPU, so I/O intensive things like
> database queries will never show up here. You could spend 5 minutes
> doing some disk action and you won't see it here because it didn't use
> much CPU.
That's exactly what I don't want to measure: I/O intensive things like
database queries. The queries run pretty fast, as I've mentioned
before. I just wanted to know where in Perl / Catalyst / DBIC land my
cycles were being spent.
> Re-run your profile on your real server, preferably without all the
> startup time, and sort it by real time with -r, then see what picture
> emerges.
I ran these tests on the actual production server.
The only difference is that I used Catalyst's builtin server because,
honestly, I have no idea regarding how to profile a mod_perl
application. But the times are somewhat consistent when comparing
Template::Timer results, so I assume the performance is somewhat the
same if there's a single user using the application.
As I've said the queries aren't the bottleneck. It's template
rendering stuff. If I just issue the query and load the objects in a
Perl array inside my Controller, without rendering the template, the
time drops significantly. Out of those 3-4 seconds, usually at least
90% of it is spent inside the "end" action (i.e. in the template
rendering stage) according to Catalyst's own debug output.
-Nilson Santos F. Jr.
More information about the Catalyst
mailing list