Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

mod_perl without persistent interpreter state?

 

 

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


pbdgny at gmail

Dec 18, 2005, 11:30 AM

Post #1 of 8 (3558 views)
Permalink
mod_perl without persistent interpreter state?

Hello,

When last I checked, mod_perl is not that great for a shared hosting
environment. 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.

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?

I did a cursory search of the mailing lists, but did not find anything.

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)

Additional performance boosts could come via:

1) Caching pre-parsed Perl "byte code" to disk/memory.
2) Provide a simple method for apps to "self-cache" in an initialized state
after the first request.

Can this be done currently, and if not, does anyone else think it a good
idea?

Thanks,
David


mjhlist-modperl at liminalflux

Dec 18, 2005, 12:07 PM

Post #2 of 8 (3402 views)
Permalink
Re: mod_perl without persistent interpreter state? [In reply to]

On Sunday 18 December 2005 02:30 pm, pbdgny[at]gmail.com 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


perrin at elem

Dec 18, 2005, 9:19 PM

Post #3 of 8 (3391 views)
Permalink
Re: mod_perl without persistent interpreter state? [In reply to]

On Sun, 2005-12-18 at 14:30 -0500, pbdgny[at]gmail.com wrote:
> 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?

Just set MaxRquestsPerChild to 1. However, most shared hosts actually
run PHP as CGI.

It really isn't worth putting much effort into supporting virtual host
ISPs now that you can have your own virtual server with root for
practically nothing.

- Perrin


pbdgny at gmail

Dec 22, 2005, 8:44 PM

Post #4 of 8 (3377 views)
Permalink
Re: mod_perl without persistent interpreter state? [In reply to]

On 12/19/05, Perrin Harkins <perrin[at]elem.com> wrote:
> > 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?
>
> Just set MaxRquestsPerChild to 1. However, most shared hosts actually
> run PHP as CGI.

Erm.. Spawning a whole new Apache process for each request seems even
worse for performance than just launching Perl via CGI. (!)

Also don't most shared hosts use mod_php, not PHP/CGI? What would be
the point of PHP via CGI? mod_php works just fine. (As long as you
stay away from threads.)

> It really isn't worth putting much effort into supporting virtual host
> ISPs now that you can have your own virtual server with root for
> practically nothing.

A virtual server for each application is even more wasteful of memory
than running a FastCGI process for each app.

This is not just about shared hosting ISPs.

See: "Tales of Perl optimization"
http://www.perl.com/pub/a/2005/12/21/a_timely_start.html

The notion of a "snapshot"-able Perl interpreter has value even
outside of the web application realm.

-- David


jon at 2xlp

Dec 22, 2005, 10:10 PM

Post #5 of 8 (3369 views)
Permalink
Re: mod_perl without persistent interpreter state? [In reply to]

On Dec 22, 2005, at 11:44 PM, <pbdgny[at]gmail.com> <pbdgny[at]gmail.com>
wrote:

> Also don't most shared hosts use mod_php, not PHP/CGI? What would be
> the point of PHP via CGI? mod_php works just fine. (As long as you
> stay away from threads.)

security.

(sorry, this is off topic, but its a response)

shared hosts were all on mod_php for a while because thats what they
thought they should do. but a funny thing happend - they realized
that mod_php lets user_a acces all of user_b's files -- because
everything runs as the apache instance user and is read/writeable by
it. so most hosts started migrating to PHP/CGI via FasctCGI, so
account holders can more easily run their scripts as a shell user.

under mod_php, unless you're running some pretty unstable other
apache_mods, you're running every php script as that single webserver
user - which is pretty unideal for a shared system from a security
standpoint.

a few shared hosts give users the option of php4 mod_php or php5 cgi/
cgi to entice them to switch to a more secure framework without
potentially breaking all of their apps (a few commands do not work)

if you're not in a shared hosting environment, then mod_php is fine.

but, if you are, some brazillian script kid can exploit a published
vulnerability in phpGallery that another user on that machine has yet
to patch, and use it to access/overwrite anything in your web
directory. fun.

a lot of design/production firms i know are abandoning mod_php for
cgi so that 1 client project runs completely separate of other client
projects that they host.

its not a bad model security wise if you're running multiple projects
on a single machine, and can be applied to mod_perl too. on my main
production server, i have things set up like this:

user: www
runs lighttpd on port 80 as proxy / vanilla1 server
runs apache-vanilla on port 8080 for general apache sites

user: wwwapp1
runs php via lighttpd fcgi on its own directory root
user: wwwapp2
runs mod_perl2 via apache2 on port 8081 bound to localhost for a
specific code group
user:www app3
runs mod_perl2 via apache2 on port 8082 bound to localhost for a
specific code group

under this setup, my 3 webapps can't screw with each other's files.

i'm sure there's a more elegant way to do it -- but that was fast and
painless for me to set up.


pbdgny at gmail

Dec 22, 2005, 11:49 PM

Post #6 of 8 (3380 views)
Permalink
Re: mod_perl without persistent interpreter state? [In reply to]

On 12/23/05, Jonathan Vanasco <jon[at]2xlp.com> wrote:
>
> On Dec 22, 2005, at 11:44 PM, <pbdgny[at]gmail.com> <pbdgny[at]gmail.com>
> wrote:
>
> > Also don't most shared hosts use mod_php, not PHP/CGI? What would be
> > the point of PHP via CGI? mod_php works just fine. (As long as you
> > stay away from threads.)
>
> security.
> [SNIP]
> i'm sure there's a more elegant way to do it -- but that was fast and
> painless for me to set up.
>

Thank you for sharing your setup.

Out of curiosity, in a case of PHP/FastCGI, despite the interpreter
staying loaded across multiple requests, does each request still get
a "blank slate" as in mod_php?

Using FastCGI is it possible to configure Perl in such a fashion? (I
have yet to hear of such a thing...)

-- David


perrin at elem

Dec 23, 2005, 8:40 AM

Post #7 of 8 (3369 views)
Permalink
Re: mod_perl without persistent interpreter state? [In reply to]

On Thu, 2005-12-22 at 23:44 -0500, pbdgny[at]gmail.com wrote:
> > Just set MaxRquestsPerChild to 1. However, most shared hosts actually
> > run PHP as CGI.
>
> Erm.. Spawning a whole new Apache process for each request seems even
> worse for performance than just launching Perl via CGI. (!)

It's not. The processes are pre-forked. Try it.

> Also don't most shared hosts use mod_php, not PHP/CGI?

Jonathan already answered this one.

> A virtual server for each application is even more wasteful of memory
> than running a FastCGI process for each app.

Of course it's heavier than running a FastCGI process. It's heavier
than running a separate mod_perl for each one too. What it's good for
is people who can't afford dedicated hardware, but still want to
actually have apache under their control, install whatever they need
from CPAN, compile mod_perl themselves so it's done right, etc.

> The notion of a "snapshot"-able Perl interpreter has value even
> outside of the web application realm.

Okay, but this is the mod_perl list and it is all about the web
application realm.

- Perrin


perrin at elem

Dec 23, 2005, 9:59 AM

Post #8 of 8 (3353 views)
Permalink
Re: mod_perl without persistent interpreter state? [In reply to]

On Fri, 2005-12-23 at 02:49 -0500, pbdgny[at]gmail.com wrote:
> Out of curiosity, in a case of PHP/FastCGI, despite the interpreter
> staying loaded across multiple requests, does each request still get
> a "blank slate" as in mod_php?

No, they are persistent just like mod_perl. The biggest difference is
that different scripts get run as separate processes in FastCGI, so one
script can't interfere with another. All the usual issues of globals,
closures, and memory use are the same though.

- Perrin

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.