Re: CGI to Apache::Registry, or to mod

It's hard to tell what's going on without seeing code, but if loading modules was taking any time at all it would be completely gone when you run under mod_perl. You're right that Apache::Util shouldn't work under CGI, but can you just check the value of $ENV{MOD_PERL} anyway?

The other possibility is that the time is being spent on something else. Maybe your script just spends lots of time writing files or something. There's nothing mod_perl can do about that.

Comment on Re: CGI to Apache::Registry, or to mod_perl

Replies are listed 'Best First'.
Re: Re: CGI to Apache::Registry, or to mod_perl by dd-b (Pilgrim) on Jan 17, 2004 at 01:05 UTC
$ENV{MOD_PERL} gives me "mod_perl/1.26", so I really really am running under mod_perl. I completely sympathize with your impulse to ask for this additional confirmation; it's behaving strangely and user error should be considered. It has occurred to me that I haven't benchmarked Apache serving a similar-sized file. Now, the ab output breaks out transfer time, and the transfer time is a totally trivial part of the total. But it doesn't break out other overhead, like URI mapping and all that. Best I get myself a datapoint on that! Okay, did that; just serving pages, Apache is using about .02 seconds. So that's not a significant part of the 2.6 seconds it's taking for my picpage to run. My initial message on the topic, pointed to by the initial message in this thread, gave some profiling numbers showing that nothing except loading modules and reading the YAML config file took "any" time (and loading modules took 5 times more than loading YAML config).	[reply]
Re: Re: Re: CGI to Apache::Registry, or to mod_perl by perrin (Chancellor) on Jan 17, 2004 at 05:46 UTC
I think there's something going on besides just loading modules that you aren't seeing with your homemade profiling. I'd say it's time to get out the big guns and run Devel::DProf, or maybe Devel::SmallProf in this case since you don't really have any subs at all in your script. Alternatively, you could run the script in the debugger, and maybe you'll discover that it's doing some things you didn't realize.	[reply]