On Sunday 18 December 2005 02:30 pm, [EMAIL PROTECTED] wrote: > When last I checked, mod_perl is not that great for a shared hosting > environment.
You share interpreters and thus it's a security and stability problem. This was supposed to be fixed by the per_child stuff in apache2 but my understanding is that it doesn't work yet. > Now I see that v.2 has accommodations for Apache vhosts, but > it still looks like each site needs it's own full blown Perl interpreter > sucking down memory. That's what mod_perl is - an embedded perl interpreter per child (not per virtual host). You can reduce the number of perl-enabled apache children by doing reverse-proxy if the overhead is a problem. > Is there a way to configure mod_perl to act more like mod_php in that each > request gets a "fresh" interpreter to work in? Use ModPerl::PerlRun as your handler. That way it throws away any global state between requests. (It's slower, but not as slow as CGI). > I did a cursory search of the mailing lists, but did not find anything. It's in the docs on the website. The PerlRun stuff is basic mp1. > This way you avoid the standard CGI setup/tear-down cycle while still > providing a way for many mutually distrustful Perl applications to coexist > on the same server. (i.e shared webhosting) I'm not sure you have sufficient security for that under PerlRun. -- It is of interest to note that while some dolphins are reported to have learned English -up to fifty words used in correct context- no human being has been reported to have learned dolphinese. - Carl Sagan