I was kind of hoping this thread would get to more helpful issues. It
did, and thanks.
It's hard for us to profile a running application, for several reasons.
(1) there is a web server in the way, and (2) the storage requirements
(and to some extent performance) are a hit. Also, a management
requirement was obfuscation that turns off debugging hooks needed for
NYTProf, so our production code cannot really be profiled. However, we
do audit mean response times for each view, and I have a few bits of
charting code in R that allow us to report on it.
We actually run a test script that models a proper workflow. This
happened because my colleagues require an old Perl tool "webinject" for
QA. I ripped the back off webinject,. stuck Catalyst::Test in its place,
and then run NYTProf on the whole thing. That way we have files that
script a fairly realistic set of requests, and we can profile the whole
bunch. Our requests vary a lot, with many simple ones and a few *really*
complex ones, so I've used scales on charts that handle the long tail.
As a side note, the Perl in webinject was somewhat hacky non-modern -
I'd love a tool as good as JMeter.
Thinking about it, if you can live with the Java interface, JMeter
rocks. It is great at modelling large sets of users with randomised
request times, and displaying how number of users affects response
latency. For performance, I don't know of anything in the Perl world to
touch it, but I'd love it if something did.
This actually evolved as we work on a problem that is distinctive to our
app under VMware ESX. We use using it to benchmark against VMware
Server, which runs 3-4 times as fast as VMware ESX at the application
level. There are *many* small differences between the two, although the
big hit seems to be MySQL memory access (of all things). Some kind of DB
issue showed up well in NYTProf, but other testing was needed to go
further. Even a tool like NYTProf will not guarantee you can find the
problem, because it may not be in Perl, let alone your app.
--S
--
Stuart Watt
ARM Product Developer
Information Balance
Matija Grabnar wrote:
Carl Johnstone wrote:
NYTProf profile or it didn't happen :-)
Is there any "best practices" or hints page on how to use Catalyst and
NYTprof? I haven't used it before and I wonder if people include it
into a running catalyst application (and then periodically review
results in some way) or if they include it only into a
just-for-profiling server which then runs a synthetic load? Or
something in between?
I've had some problems with a catalyst application lately, but it
turned out that it was caused by the FCGI servers being swapped out:
no ammount of tweaking my code would have solved it, all it took was
an extra $10/month for another 256M RAM.
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
--
This message was scanned by ESVA and is believed to be clean.
Click here to report this message as spam.
http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=43BA02807E.D8421
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/