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"
Hub.org has mod_perl support, I've been very happy with them -Original Message- From: Martin RJ Cleaver [mailto:[EMAIL PROTECTED] Sent: August 29, 2004 8:54 AM To: [EMAIL PROTECTED] 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
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
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 [EMAIL PROTECTED] 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"
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"
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"
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"
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 <[EMAIL PROTECTED]> 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 scriptrunnung as a cgi.A well designed mod_perl application loads as many shared libraries aspossible before Apache forks off the child processes. This takesadvantage of the standard "copy-on-write" behavior of the fork() systemcall; meaning that only the portions of the process memory that differfrom the parent will actually take up extra memory, the rest is sharedwith the parent until one of them tries to write to that memory, atwhich 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'tperfect either: it mixes code and data segments together throughout theprocess address space. This has the effect that as the code runs andvariables/structures are changed, some of the surrounding code segmentsin the memory space are swept up into the memory chunks during acopy-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 andrespawn after a certain number requests have been served, therebyforcing the child process to "start fresh" with the maximum amount ofshared memory.In the long run, this means that if you pre-load as many sharedlibraries as possible and tweak the MaxRequestsPerChild directive,you'll probably see significantly less memory usage on average. Not tomention all the other speed and efficiency increases that you're alreadymod_perl provides.j--[EMAIL PROTECTED] (please don't reply to @yahoo)Post your free ad now! Yahoo! Canada Personals
Re: Hosting provider disallows mod_perl - "memory hog / unstable"
> > 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 > > > > -- > [EMAIL PROTECTED] (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"
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"
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"
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