On Friday 13 June 2003 13:57, Stas Bekman wrote:
Since your question is too broad to be able to easily pinpoint any problems without spending some time with it, I'd suggest reading: http://perl.apache.org/docs/1.0/guide/performance.html if you haven't done that yet.
I have. Although it was several years ago now. Has much changed?
It wasn't updated much in the last year. But I did lots of updates a year before when working on the "Practical mod_perl" book.
I'll take a look, but I haven't seen anything in there that correlates to the sort of results I'm seeing. This isn't a perl load-time issue, and it's not a small set slow-down - it's a percentage slow-down on pages of which can take up to 10 seconds to generate and return. It's something run-time, which is different between mod_perl and FastCGI. It's bizarre...
As I said, if you were asking more specific question or showing code samples which are slower in mod_perl than they are in FastCGI, it'd be easier to know how to tune the setup. That's why sending you to the document was the best I could do in the current situation.
Have you heard of Apache::Reload. http://perl.apache.org/docs/1.0/guide/porting.html#Reloading_Modules_and_Re quired_Files
I have now. How does it handle syntax errors? Does it kill the whole server, keep the old module running, or just kill that module?
it calls require(), so if that fails, the old version stays in memory. Nothing gets killed. I use it all the time and it saves me heaps of time. Give it a try.
As a FastCGI, all I have to do to restart it is touch the main CGI file. I also have tighter control on the number of FastCGI processes, which is more useful for development.
Looks like you may need to do some docs reading. You can easily get a total control over the number of mod_perl processes. It's all described here: http://perl.apache.org/docs/1.0/guide/performance.html
Uh, yes, I can limit the Apache processes, but again, that will impact other users on the system. Really, FastCGI does just what I want, and it means I can write a module that works either as a FastCGI or a module. For content modules, that's fine. I've written a myriad of access modules, loggers, trans handlers, etc... For those, yes, they're mod_perl exclusives. But for some purposes, I find FastCGI more efficient.
I'd almost be tempted to leave this app as a FastCGI - except for some places we use it we stack with other mod_perl content handlers. And I'm just baffled at this particular performance problem, since I have been through the standard things to check for.
As Perrin said in his reply, we are always interested in features that can be added to mod_perl to make it more convenient to developers. Your answer so far doesn't give much insight on what FastCGI feature provides to control the number of processes in the multi-developers environment and is missing in mod_perl. I'm not familiar with FastCGI myself, so if you can be more specific about this feature, that would help.
Thanks.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
