You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Martin RJ Cleaver <Ma...@BCS.org.uk> on 2004/08/29 17:53:34 UTC
Hosting provider disallows mod_perl - "memory hog / unstable"
https://panel.dreamhost.com/kbase/index.cgi?area=2446 says:
"We do not support mod_perl on our shared hosting plans.
We're sorry about this; the problem is that mod-perl is just too
much of a memory hog to attach to Apache (the web serving software),
and it introduces a great deal of instability to our systems.
We are looking into ways to provide mod_perl in the future, but do
not currently have a time line in place."
As I see it, Mod_perl provides two things: 1) speed and 2)
functionality in terms of an operating environment.
The application I want to run (WebGUI) needs mod_perl for its
operating environment - is there some setting that is going to
reassure my hosting provider that they can run mod_perl and that the
mod_perl module (or my context) will get swapped out after a short
period of time? I don't intend to be hitting my WebGUI application
very often so I'm not too concerned about speed.
Thanks,
Martin.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by Brian Reichert <re...@numachi.com>.
On Sun, Aug 29, 2004 at 03:53:34PM -0000, Martin RJ Cleaver wrote:
> The application I want to run (WebGUI) needs mod_perl for its
> operating environment - is there some setting that is going to
> reassure my hosting provider that they can run mod_perl and that the
> mod_perl module (or my context) will get swapped out after a short
> period of time? I don't intend to be hitting my WebGUI application
> very often so I'm not too concerned about speed.
Can you run a local instance of Apache w/ mod_perl on an unpriviledged
port, and tunnel requests to it?
> Thanks,
> Martin.
--
Brian Reichert <re...@numachi.com>
37 Crystal Ave. #303 Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by "JupiterHost.Net" <ml...@jupiterhost.net>.
Martin RJ Cleaver wrote:
> https://panel.dreamhost.com/kbase/index.cgi?area=2446 says:
>
> "We do not support mod_perl on our shared hosting plans.
>
> We're sorry about this; the problem is that mod-perl is just too
> much of a memory hog to attach to Apache (the web serving software),
> and it introduces a great deal of instability to our systems.
Err, do they have PHP? Its more of a memory/resource hog and is more
unstable, assuming the same task and similar programming technique.
(I make this statement as someone who has to rebuild at least one apache
per day due to PHP problems and troubleshoot resource useage issues that
usually go down to a badly written PHP scripts)
So am I saying that PHP is worse than mod_perl, in *my* experience that
is a huge YES, so if your host is that ignorant I'd find one that has a
clue what they are talking about.
I'd go into more detail but I'm too busy using mod_perl and fixing PHP
;p
> We are looking into ways to provide mod_perl in the future, but do
> not currently have a time line in place."
>
> As I see it, Mod_perl provides two things: 1) speed and 2)
> functionality in terms of an operating environment.
PersistantPerl is nice to and can be used via apache or not
HTH :)
Lee.M - JupiterHost.Net
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by David Hodgkinson <da...@rockitfactory.com>.
On 11 Sep 2004, at 20:35, Will Yardley wrote:
> But businesses don't just let various random people off the street
> write code and then load it on their servers.
Explain the success of PHP then. Apparently the cross-site holes
were tolerable for long enough...
> Will Yardley (of DreamHost)
You guy suck a lot less than most ;-)
--
Dave Hodgkinson
CTO, Rockit Factory Ltd.
http://www.rockitfactory.com/
Web sites for rock bands
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by Perrin Harkins <pe...@elem.com>.
Hi Will,
Thanks for taking the time to respond. What bothered me about your
policy is that it accuses mod_perl of these things, and yet you offer
PHP as an apache module. PHP has plenty of security issues when you
don't run it as CGI, and you can certainly crash the server with it.
> I'll see if we can update the kbase entry to be a little more specific
> and not to sound so much like we're blaming mod_perl itself (not our
> intent).
Thank you, that would be much appreciated. I think that offering it on
dedicated hosts (or virtual machines) is the best approach, and I'm glad
see that you fully support that.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by Will Yardley <mo...@veggiechinese.net>.
On Mon, Aug 30, 2004 at 02:12:27PM -0400, Perrin Harkins wrote:
> On Sun, 2004-08-29 at 11:53, Martin RJ Cleaver wrote:
[ Got a pointer to this thread, so just responding to clear a few things
up ]
> > https://panel.dreamhost.com/kbase/index.cgi?area=2446 says:
> > "We do not support mod_perl on our shared hosting plans.
> >
> > We're sorry about this; the problem is that mod-perl is just
> > too much of a memory hog to attach to Apache (the web serving
> > software), and it introduces a great deal of instability to our
> > systems.
> You can do things under mod_perl like load tons of stuff into a
> global variable, but that would be the programmer's fault, not
> mod_perl's.
Right - but in a shared hosting environment, especially a mostly
automated one, we have very little control over customers' code. And,
since we have (a lot) more than one customer on each instance of Apache,
mod_perl allows customers to write code that will either prevent the
Apache from starting at all, or even bring down an entire machine (hence
the "instability" comment). Providing an entire instance of Apache for
each mod_perl site isn't really feasible for us either.
I'll see if we can update the kbase entry to be a little more specific
and not to sound so much like we're blaming mod_perl itself (not our
intent).
We used to support mod_perl on shared hosting plans; it caused too
many problems for us. I'm not aware of (m)any large webhosts that
provide this... but I fully encourage someone who /absolutely/ needs
to run mod_perl for some reason to either look into our dedicated
plans, or to try a host which does support mod_perl on their shared
hosting plans.
> As for stability, businesses use mod_perl to handle their mission
> critical sites every day. It's as stable as any other web
> development system. This sounds like FUD to me, or blaming someone's
> bad code on mod_perl instead of the coder.
But businesses don't just let various random people off the street
write code and then load it on their servers.
We use mod_perl (extensively) ourselves for our own ("mission
critical") web stuff, including our web panel. We like mod_perl.
Regards,
Will Yardley (of DreamHost)
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by James Smith <js...@sanger.ac.uk>.
>
> That's not entirely true. It is in fact the case that mod_perl's
> *upper-bound* on memeroy usage is similar to the equivalent script
> runnung as a cgi.
>
> A well designed mod_perl application loads as many shared libraries as
> possible before Apache forks off the child processes. This takes
> advantage of the standard "copy-on-write" behavior of the fork() system
> call; meaning that only the portions of the process memory that differ
> from the parent will actually take up extra memory, the rest is shared
> with the parent until one of them tries to write to that memory, at
> which time it is copied before the change is made, effectively
> "unsharing" that chunck of memory.
>
> Unfortunately, it's not a perfect world, and the Perl interpreter isn't
> perfect either: it mixes code and data segments together throughout the
> process address space. This has the effect that as the code runs and
> variables/structures are changed, some of the surrounding code segments
> in the memory space are swept up into the memory chunks during a
> copy-on-write, thereby slowly duplicating the memory between processes
> (where the code would ideally be indefinitely shared).
> Fortunately, Apache has a built in defence against this memory creep:
> the MaxRequestsPerChild directive forces a child process to die and
> respawn after a certain number requests have been served, thereby
> forcing the child process to "start fresh" with the maximum amount of
> shared memory.
The bigger problem is that if one of the modules you include in the
pre-fork is foobarred you may/will not be able to start the server...
> In the long run, this means that if you pre-load as many shared
> libraries as possible and tweak the MaxRequestsPerChild directive,
> you'll probably see significantly less memory usage on average. Not to
> mention all the other speed and efficiency increases that you're already
> mod_perl provides.
Apache::SizeLimit is a better approach as it only reaps large children!!
> j
>
>
>
> --
> Martin@Cleaver.org (please don't reply to @yahoo)
>
>
> ---------------------------------
> Post your free ad now! Yahoo! Canada Personals
>
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by "Martin@Cleaver.org" <mr...@yahoo.co.uk>.
Hi all,
Thank you all for your responses, I am getting a better picture now.
I guess my hosting provider's concern is that they have a lot of clients who have infrequently running scripts. By design, mod_perl keeps things in memory for longer so that subsequent calls do not incur a reload of the environment. By restricting use to CGI they get such infrequently used environments unloaded ASAP.
Is there a way to configure mod_perl to aggressively unload perl instantiations such that it holds onto data for the minimum timespan?
Thanks,
Martin.
Jeff Norman <jn...@fx0.net> wrote:
On Mon, 2004-08-30 at 14:12, Perrin Harkins wrote:
> The truth is that mod_perl uses the same amount of memory that Perl CGI
> scripts use. The difference is that CGI scripts exit as soon as they
> finish. Serving 10 simultaneous requests with CGI requires the same
> amount of memory as it does with mod_perl (with a small amount extra for
> the apache interface modules). You can do things under mod_perl like
> load tons of stuff into a global variable, but that would be the
> programmer's fault, not mod_perl's.
That's not entirely true. It is in fact the case that mod_perl's
*upper-bound* on memeroy usage is similar to the equivalent script
runnung as a cgi.
A well designed mod_perl application loads as many shared libraries as
possible before Apache forks off the child processes. This takes
advantage of the standard "copy-on-write" behavior of the fork() system
call; meaning that only the portions of the process memory that differ
from the parent will actually take up extra memory, the rest is shared
with the parent until one of them tries to write to that memory, at
which time it is copied before the change is made, effectively
"unsharing" that chunck of memory.
Unfortunately, it's not a perfect world, and the Perl interpreter isn't
perfect either: it mixes code and data segments together throughout the
process address space. This has the effect that as the code runs and
variables/structures are changed, some of the surrounding code segments
in the memory space are swept up into the memory chunks during a
copy-on-write, thereby slowly duplicating the memory between processes
(where the code would ideally be indefinitely shared).
Fortunately, Apache has a built in defence against this memory creep:
the MaxRequestsPerChild directive forces a child process to die and
respawn after a certain number requests have been served, thereby
forcing the child process to "start fresh" with the maximum amount of
shared memory.
In the long run, this means that if you pre-load as many shared
libraries as possible and tweak the MaxRequestsPerChild directive,
you'll probably see significantly less memory usage on average. Not to
mention all the other speed and efficiency increases that you're already
mod_perl provides.
j
--
Martin@Cleaver.org (please don't reply to @yahoo)
---------------------------------
Post your free ad now! Yahoo! Canada Personals
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by Jeff Norman <jn...@fx0.net>.
On Mon, 2004-08-30 at 14:12, Perrin Harkins wrote:
> The truth is that mod_perl uses the same amount of memory that Perl CGI
> scripts use. The difference is that CGI scripts exit as soon as they
> finish. Serving 10 simultaneous requests with CGI requires the same
> amount of memory as it does with mod_perl (with a small amount extra for
> the apache interface modules). You can do things under mod_perl like
> load tons of stuff into a global variable, but that would be the
> programmer's fault, not mod_perl's.
That's not entirely true. It is in fact the case that mod_perl's
*upper-bound* on memeroy usage is similar to the equivalent script
runnung as a cgi.
A well designed mod_perl application loads as many shared libraries as
possible before Apache forks off the child processes. This takes
advantage of the standard "copy-on-write" behavior of the fork() system
call; meaning that only the portions of the process memory that differ
from the parent will actually take up extra memory, the rest is shared
with the parent until one of them tries to write to that memory, at
which time it is copied before the change is made, effectively
"unsharing" that chunck of memory.
Unfortunately, it's not a perfect world, and the Perl interpreter isn't
perfect either: it mixes code and data segments together throughout the
process address space. This has the effect that as the code runs and
variables/structures are changed, some of the surrounding code segments
in the memory space are swept up into the memory chunks during a
copy-on-write, thereby slowly duplicating the memory between processes
(where the code would ideally be indefinitely shared).
Fortunately, Apache has a built in defence against this memory creep:
the MaxRequestsPerChild directive forces a child process to die and
respawn after a certain number requests have been served, thereby
forcing the child process to "start fresh" with the maximum amount of
shared memory.
In the long run, this means that if you pre-load as many shared
libraries as possible and tweak the MaxRequestsPerChild directive,
you'll probably see significantly less memory usage on average. Not to
mention all the other speed and efficiency increases that you're already
mod_perl provides.
j
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by Perrin Harkins <pe...@elem.com>.
On Sun, 2004-08-29 at 11:53, Martin RJ Cleaver wrote:
> https://panel.dreamhost.com/kbase/index.cgi?area=2446 says:
>
> "We do not support mod_perl on our shared hosting plans.
>
> We're sorry about this; the problem is that mod-perl is just too
> much of a memory hog to attach to Apache (the web serving software),
> and it introduces a great deal of instability to our systems.
>
> We are looking into ways to provide mod_perl in the future, but do
> not currently have a time line in place."
The truth is that mod_perl uses the same amount of memory that Perl CGI
scripts use. The difference is that CGI scripts exit as soon as they
finish. Serving 10 simultaneous requests with CGI requires the same
amount of memory as it does with mod_perl (with a small amount extra for
the apache interface modules). You can do things under mod_perl like
load tons of stuff into a global variable, but that would be the
programmer's fault, not mod_perl's.
As for stability, businesses use mod_perl to handle their mission
critical sites every day. It's as stable as any other web development
system. This sounds like FUD to me, or blaming someone's bad code on
mod_perl instead of the coder.
Anyway, you can look at using something like SpeedyCGI, which does not
require root access and offers similar speed to mod_perl, or you can
find a better ISP. It's quite inexpensive to get your own virtual Linux
system these days, so it may not be worth arguing with an ISP that won't
cooperate.
- Perrin
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by Stas Bekman <st...@stason.org>.
Jean-Michel Hiver wrote:
> Gossamer-Threads has a pretty cool mod_perl setup. You can get a
> dedicated server or a shared account. Each shared account has its own
> apache process, which means that you can log in and control (i.e. stop /
> start / restart) your own modperl httpd.
>
> All the mod_perl processes are behind a small, minimal apache proxy +
> mod_gzip which manages the virtual hosting, slow connections and gzip
> compression. I was recently visiting them in Vancouver and their system
> is pretty clever IMHO.
>
> http://www.gossamer-host.com/
>
Don't forget to send us updates to:
http://perl.apache.org/help/isps.html
I've added http://www.gossamer-host.com and http://systame.com/ to it.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by Jean-Michel Hiver <jh...@mkdoc.com>.
Gossamer-Threads has a pretty cool mod_perl setup. You can get a
dedicated server or a shared account. Each shared account has its own
apache process, which means that you can log in and control (i.e. stop /
start / restart) your own modperl httpd.
All the mod_perl processes are behind a small, minimal apache proxy +
mod_gzip which manages the virtual hosting, slow connections and gzip
compression. I was recently visiting them in Vancouver and their system
is pretty clever IMHO.
http://www.gossamer-host.com/
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by Randall Perry <rg...@systame.com>.
We offer mod_perl support on shared hosting plans:
http://systame.com/html/web_hosting_plans.html
on 8/29/04 11:53 AM, Martin RJ Cleaver at Martin.Cleaver@BCS.org.uk wrote:
> https://panel.dreamhost.com/kbase/index.cgi?area=2446 says:
>
> "We do not support mod_perl on our shared hosting plans.
>
> We're sorry about this; the problem is that mod-perl is just too
> much of a memory hog to attach to Apache (the web serving software),
> and it introduces a great deal of instability to our systems.
>
> We are looking into ways to provide mod_perl in the future, but do
> not currently have a time line in place."
>
> As I see it, Mod_perl provides two things: 1) speed and 2)
> functionality in terms of an operating environment.
>
> The application I want to run (WebGUI) needs mod_perl for its
> operating environment - is there some setting that is going to
> reassure my hosting provider that they can run mod_perl and that the
> mod_perl module (or my context) will get swapped out after a short
> period of time? I don't intend to be hitting my WebGUI application
> very often so I'm not too concerned about speed.
>
> Thanks,
> Martin.
>
--
Randall Perry
sysTame
Xserve Web Hosting/Co-location
Website Design/Development
WebObjects Hosting
Mac Consulting/Sales
http://www.systame.com/
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: Hosting provider disallows mod_perl - "memory hog / unstable"
Posted by Clayton Cottingham <dr...@telus.net>.
Hub.org has mod_perl support, I've been very happy with them
-----Original Message-----
From: Martin RJ Cleaver [mailto:Martin.Cleaver@BCS.org.uk]
Sent: August 29, 2004 8:54 AM
To: modperl@perl.apache.org
Subject: Hosting provider disallows mod_perl - "memory hog / unstable"
https://panel.dreamhost.com/kbase/index.cgi?area=2446 says:
"We do not support mod_perl on our shared hosting plans.
We're sorry about this; the problem is that mod-perl is just too
much of a memory hog to attach to Apache (the web serving software),
and it introduces a great deal of instability to our systems.
We are looking into ways to provide mod_perl in the future, but do
not currently have a time line in place."
As I see it, Mod_perl provides two things: 1) speed and 2)
functionality in terms of an operating environment.
The application I want to run (WebGUI) needs mod_perl for its
operating environment - is there some setting that is going to
reassure my hosting provider that they can run mod_perl and that the
mod_perl module (or my context) will get swapped out after a short
period of time? I don't intend to be hitting my WebGUI application
very often so I'm not too concerned about speed.
Thanks,
Martin.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html