in reply to mod_perl without separate config for static HTML?

The trouble is, performance isn't as simple as "X is faster than Y". It's a series of complex trade-offs. For example, mod_perl causes Apache processes to have a larger memory footprint. Depending on what you're doing, it may well be worse if you're running under Apache::Registry, especially if your CGI scripts aren't tuned to run under it. However, the execution time is generally far superior to CGI. In a lot of cases, it's better to use more memory than to run slowly.

Of course, this is not always the case. It's all highly dependant on exactly what you're doing, what the goals of the project are, etc.

There's a strong possibility that performance isn't as important for your application as you think. There isn't a huge amount of difference between the performance of mod_perl using custom handlers, mod_perl using Apache::Registry and PHP using mod_php, at least for the vast majority of applications. Unless your requirements specifically state 'X must run in n seconds or less', I wouldn't let performance be a huge factor in whether I chose PHP over Perl

  • Comment on Re: mod_perl without separate config for static HTML?

Replies are listed 'Best First'.
Re^2: mod_perl without separate config for static HTML?
by gunzip (Pilgrim) on Oct 26, 2004 at 16:26 UTC
    Performance isn't what my posts referred to. I take your point about the speed issue. It's the memory per process for static content that concerns me. If mod_whatever is adding a significant amount of memory overhead which is redundant for static content then that concerns me.