Re: web application speed problem with OO modules
First, give dprofpp the flag that makes it sort by wall time, not by CPU time. Otherwise, things that take most of the time in the average program, like I/O, will appear to be very fast. Second, make sure you initialize the debugger before loading any of the code that you want to profile, like this: require Apache::DB; Apache::DB->init; Any code that you compile (e.g. use from startup.pl) before this will not get profiled at all. - Perrin Thanks for the replies... I'll give it a try... --- Badai Aqrandista Cheepy (?) _ SEEK: Over 80,000 jobs across all industries at Australia's #1 job site. http://ninemsn.seek.com.au?hotmail
Re: web application speed problem with OO modules
On Mon, 15 Aug 2005 11:42:52 -0400 Perrin Harkins <[EMAIL PROTECTED]> wrote: > Frank Wiles wrote: > > Give Apache::SmallProf a try. Where Apache::DProf shows you the > > subroutine calls, SmallProf will show you a profile on a line by > > line basis. This should help you zero in on what is causing the > > slowness. > > I'd say just the opposite in most cases. Usually you want to see > which subs are taking the time. SmallProf is mostly useful when your > subs are much too big. > > It is very common though for people to not properly initialize the > debugger when using DProf and thus not get results for most of their > code. That often leads them to think they should use a different > profiler, like SmallProf. Yup that's exactly what I was thinking, I should have thought about the initialization issue. - Frank Wiles <[EMAIL PROTECTED]> http://www.wiles.org -
Re: web application speed problem with OO modules
Frank Wiles wrote: Give Apache::SmallProf a try. Where Apache::DProf shows you the subroutine calls, SmallProf will show you a profile on a line by line basis. This should help you zero in on what is causing the slowness. I'd say just the opposite in most cases. Usually you want to see which subs are taking the time. SmallProf is mostly useful when your subs are much too big. It is very common though for people to not properly initialize the debugger when using DProf and thus not get results for most of their code. That often leads them to think they should use a different profiler, like SmallProf. - Perrin
Re: web application speed problem with OO modules
Badai Aqrandista wrote: I doubt the ApacheHandler::handler subroutine runs that long, because it only shows the accumulated time used by other subroutines it calls. That makes the profile isn't really accurate. How do I make it to show the statistics of the subroutines called from the handler? First, give dprofpp the flag that makes it sort by wall time, not by CPU time. Otherwise, things that take most of the time in the average program, like I/O, will appear to be very fast. Second, make sure you initialize the debugger before loading any of the code that you want to profile, like this: require Apache::DB; Apache::DB->init; Any code that you compile (e.g. use from startup.pl) before this will not get profiled at all. - Perrin
Re: web application speed problem with OO modules
On Mon, 15 Aug 2005 14:59:00 +1000 "Badai Aqrandista" <[EMAIL PROTECTED]> wrote: > I doubt the ApacheHandler::handler subroutine runs that long, because > it only shows the accumulated time used by other subroutines it > calls. That makes the profile isn't really accurate. How do I make it > to show the statistics of the subroutines called from the handler? Give Apache::SmallProf a try. Where Apache::DProf shows you the subroutine calls, SmallProf will show you a profile on a line by line basis. This should help you zero in on what is causing the slowness. - Frank Wiles <[EMAIL PROTECTED]> http://www.wiles.org -
Re: web application speed problem with OO modules
Thanks for replying... I have done some profiling with Apache::DProfile, and this is the output of 'dprofpp tmon.out': Total Elapsed Time = 160.2141 Seconds User+System Time = 13.07412 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 92.7 12.12 13.575 1 12.127 13.574 ELRes::ApacheHandler::handler 3.13 0.409 0.409 90360 0. 0. Date::Simple::as_iso 2.20 0.288 0.366 20364 0. 0. Params::Validate::_check_regex_fro m_xs 1.53 0.200 0.200 29966 0. 0. Date::Simple::DESTROY 1.35 0.177 0.177 6565 0. 0. Storable::mretrieve 0.66 0.086 0.086 36878 0. 0. Date::Simple::_compare 0.58 0.076 0.076 1761 0. 0. DBD::_::db::prepare_cached 0.46 0.060 0.060 24782 0. 0. Date::Simple::_add 0.32 0.042 0.042 2900 0. 0. ELRes::Entity::DESTROY 0.25 0.033 0.033 3700 0. 0. DBI::common::FETCH 0.18 0.023 0.023 3692 0. 0. DBI::st::fetch 0.12 0.016 0.016 1756 0. 0. ELRes::DB::DESTROY 0.08 0.011 0.011 9528 0. 0. Date::Simple::__ANON__ 0.08 0.010 0.010 1 0.0100 0.0100 DynaLoader::bootstrap 0.08 0.010 0.010 2 0.0050 0.0050 DBD::mysql::db::_login I doubt the ApacheHandler::handler subroutine runs that long, because it only shows the accumulated time used by other subroutines it calls. That makes the profile isn't really accurate. How do I make it to show the statistics of the subroutines called from the handler? Thank you... --- Badai Aqrandista Cheepy (?) From: "Philip M. Gollucci" <[EMAIL PROTECTED]> To: Badai Aqrandista <[EMAIL PROTECTED]> CC: modperl@perl.apache.org Subject: Re: web application speed problem with OO modules Date: Mon, 15 Aug 2005 00:32:09 -0400 (I only try to improve the speed of the code, so the use of proxy shouldn't be relevant here - I think, I could be wrong). You might try using Apache::DProf and/or Apache::SmallProf available here to see where your code is spending its time http://search.cpan.org/~fwiles/Apache-DB _ Low rate ANZ MasterCard. Apply now! http://clk.atdmt.com/MAU/go/msnnkanz003006mau/direct/01/ Must be over 18 years.
Re: web application speed problem with OO modules
(I only try to improve the speed of the code, so the use of proxy shouldn't be relevant here - I think, I could be wrong). You might try using Apache::DProf and/or Apache::SmallProf available here to see where your code is spending its time http://search.cpan.org/~fwiles/Apache-DB
web application speed problem with OO modules
Hi all, I'm new to the list and I have a question related to mod_perl... I have tried my best to solve the problem, but failed... So I turn to you guys... I'm currently in the process of optimizing a my company's web application that I've rewritten almost from scratch for 4 months. The older version uses Apache::Registry, slightly modified cgi scripts and procedural perl modules. Whereas the new version is a rewrite of all those into object oriented modules, with Template Toolkit as the templating system. The code has become much more manageable now. However, the speed of the new code is a LOT worse than what I had expected. I have optimized the code with caches, indexes and rewriting inefficient SQL queries. But the speed is still 2 to 4 times slower than the old version for the same algorithm. (Of course I only optimized what the profiler tells me). (I only try to improve the speed of the code, so the use of proxy shouldn't be relevant here - I think, I could be wrong). Does anyone has any other suggestion to improve a web application's speed? I'd give more details if needed... Thanks for your attentions... --- Badai Aqrandista Cheepy (?) _ Dating? Try Lavalife get 7 days FREE! Sign up NOW. http://www.lavalife.com/clickthru/clickthru.act?id=ninemsn&context=an99&a=20233&locale=en_AU&_t=33473
