Re: mod_perl virtual web hosting

[Jesse Wolfe <je...@allheal.com>]

I am working with www.superb.net to get their mod_perl up and working
again. They have great infrastrucure, lots of great tools, and an amazing
price.
They had apache/mod_perl for awhile, and upgrades broke it.  I expect they
will have it in a week or two, if we can use all these dynamic/shared
modules as planned. 

I'm moving my mod-perl project there once I get it going. Have you checked
out the list on perl.apache.org's documentation?

Jesse


At 01:26 PM 4/12/00 -0400, Gagan Prakash wrote:
>Hello,
>
>I have been looking for mod_perl virtual web hosting companies who have fast
>servers and good infrastructure but the two I have found so far have either
>had problems with their mod_perl setups (they installed the module, did not
>change apache configs or changed them incorrectly) or have been very slow.
>These two are www.123hostme.com or www.olm.net.
>
>I would greatly appreciate if somebody could point me in a better direction.
>
>Thanks
>Gagan
>
>
>********** Web App Development  Needs? ***************
>          Contact OSATech today! http://www.OSATech.com
>***************************************************
>
>----- Original Message -----
>From: "Jason Murphy" <jm...@lawinfo.com>
>To: "Doug MacEachern" <do...@covalent.net>
>Cc: <mo...@apache.org>
>Sent: Wednesday, April 12, 2000 1:09 PM
>Subject: Re: $r->args troubles...
>
>
>>
>> You would have guessed right. However, the problem was two fold in my
>case.
>>
>> First, I was not calling Apache::Request correctly. The proper method to
>> call Apache was told to me by Doug Kyle (Giving credit where due!). Below
>is
>> how it is done.
>>
>> <--- Begin Example
>>
>> my $r = Apache->request;
>> my $apr = Apache::Request->new($r);
>>
>> my %params = $apr->args;
>>
>> print $params{"Player"};
>>
>> <---- End Example
>>
>> The 'print $params{"Player"}' would be used to get and print something
>like
>> the parameters from the URL of a GET like
>> "www.example.com/find_player.pl?Player=Mullen" (Not a real site, dont
>> click!).
>>
>> Second part of my problem was that I had an error in my Apache::Registry
>> setup in Apache.conf or perl.conf (Can't remember where I put it). The
>> script I was running was not being picked up by Apache::Registry and thus
>> not working.
>>
>>  Thanks for everyone's help.
>>
>> PS. The only reason I say this on the mailing list is to get it in to the
>> mailing list archives because I could not my solution there when I looked.
>>
>>
>> From: "Doug MacEachern" <do...@covalent.net>
>> To: "Jason Murphy" <jm...@lawinfo.com>
>> Cc: <mo...@apache.org>
>> Sent: Tuesday, April 11, 2000 8:52 PM
>> Subject: Re: $r->args troubles...
>>
>> > On Fri, 7 Apr 2000, Jason Murphy wrote:
>> > > Can't locate object method "new" via package "Apache::Request" at
>> > > ./find_player.pl line 10.
>> >
>> > that would normally indicate your script is running under mod_cgi, not
>> > mod_perl.
>> >
>> > > my $r = new Apache::Request;  <---Where the error appears
>> >
>> > in any case, you need to change that to:
>> >
>> > my $r = Apache::Request->new(shift);
>> > or
>> > my $r = Apache::Request->new(Apache->request);
>> >
>> >
>>
>> --
>>  Jason Murphy
>>  System Administrator
>>  Lawinfo.com
>>  1-800-397-3743 ex: 133
>>
>>
>>
>
>
----
Jesse Wolfe, ICQ #19734806
AllHeal, a Global Healing Village
"Healing our World, One Life at a Time."
http://www.allheal.com
Want to pay less for long distance? - http://ld.net?claritycom
 

Re: mod_perl virtual web hosting

[Gunther Birznieks <gu...@extropia.com>]

While I understand that it might be an "advantage" to allow the customer's 
their own mix of modules, it can also be a bit of a support headache as 
different customers will be loading different DSOs presumably even in 
different orders. There may be subtle bugs with module interaction that 
providing a standard set of one or two Apache binaries would solve for the ISP.

However, I do agree that you should not compile in mod_perl and other 
modules like it by default for the front-end servers.... The reason is 
security. Core Apache is complicated enough without adding to the potential 
for buffer overflows.  The more lines of code you add, the greater the 
likelihood of bugs, some of those bugs have a likelihood of being security 
bugs.

By only having a subset of users using a DSO, or making a back-end server 
use this stuff, you could limit the possibility that the main web server 
itself is subject to the overflow (although this is still a risky scenario, 
it is less risky than compiling everything in one monolithic apache) since 
the front-end could be designed to have very little in it except for an 
Intrusion Detection system (which I am under the impression that someone is 
writing?).

Anyway, I guess it all boils down to balance and the risks (either support 
or security) you are willing to take as an ISP. Adding mod_perl certainly 
is a risk in itself! But one that I think many of us definatley would not 
mind paying extra for as a dedicated server solution is extremely expensive 
as it is.

Later,
    Gunther

At 04:26 PM 4/12/00 +0000, Jesse Wolfe wrote:
>At 02:54 PM 4/12/00 -0700, Tom Brown wrote:
> >On Wed, 12 Apr 2000, Jesse Wolfe wrote:
> >
> >> I am working with www.superb.net to get their mod_perl up and working
> >> again. They have great infrastrucure, lots of great tools, and an amazing
> >> price.
> >> They had apache/mod_perl for awhile, and upgrades broke it.  I expect they
> >> will have it in a week or two, if we can use all these dynamic/shared
> >> modules as planned.
> >
> >strikes me (as an owner of a web hosting service) that DSO is the wrong
> >answer. What does DSO buy you? NOTHING except a complete waste of
> >memory...
>
>well, it would let each customer add their own combo of modules to their
>apache server without requiring either two installs (one with, one without
>mod_perl) or making everyone's server run mod_perl even if they aren't
>using it.
>
>But it is a good question... I found it kind of unusual to request that
>EVERY Apache module be dso, including mod_perl, mod_ssl, PHP3, and libdav.
>I'm not even sure that it's possible that it will run well. Any advise
>anyone has here would be most appreciated.
>
>I'm actually kind of surprised I got mod_perl DSO 'make test' to pass at all.
>
> >
> >I'm reading between the lines here, but it sounds like you are trying to
> >have _one_ parent apache daemon that services _everything_ on the machine
> >(likely _more_ than one website), which would imply that you are going to
> >have an _extremely_ low hit ratio on your mod_perl scripts.
>
>nahh, that's not where we were going with it. I am pretty sure it's just a
>"maximum flexibility" feature they want to have on hand to minimize tech
>support, etc.  Why does DSO waste so much memory? I thought DSO would mean
>all processes share the resident copy of the perl library?
>
> >
> >it strikes me that you _want_ a frontend proxy to feed your requests to
> >the smallest number of backend daemons which are most likely to already
> >have compiled your scripts. This saves memory and CPU, while simplifying
> >the configuration, and of course, for a dedicated backend daemon, DSO buys
> >nothing... even if that daemon uses access handlers, it still always needs
> >mod_perl
>
>remember we're talking an entire ISP, not just a website. I think it might
>be a mighty pain to have everyone running or sharing some backend mod_perl
>server. Logs and all that.
>
> >
> >That said, we bought modperl-space.com back when domains suddenly got
> >cheap, but haven't put together a mod_perl package because we really don't
> >know what folks want/are using it for.
>
>seems like most folks with enough ?? to be using mod_perl are either
>working corporate or have their own hosts and don't have to deal with ISP's
>on the mod_perl issue.  With all this talk about mod_perl programmers being
>needed, I'm surprised to find so few ISP's offering it.  Bottom line it
>seems you need to be able to keep a mod_perl guru on hand just to keep it
>going... the compilation, etc. of it is so complex. I actually need to
>leave my original mod_perl isp because they just don't have the staff to
>make the right mods to their system, even if I figure it out for them.
>Their mod_perl person got up and left and they can't seem to hire a
>replacement. Anyone in Boston area would like to work with a pretty decent
>ISP?
>
>Regards,
>
>Jesse
>
>

Re: mod_perl virtual web hosting

[Tom Brown <tb...@baremetal.com>]

> >
> >I'm reading between the lines here, but it sounds like you are trying to
> >have _one_ parent apache daemon that services _everything_ on the machine
> >(likely _more_ than one website), which would imply that you are going to
> >have an _extremely_ low hit ratio on your mod_perl scripts.
> 
> nahh, that's not where we were going with it. I am pretty sure it's just a
> "maximum flexibility" feature they want to have on hand to minimize tech
> support, etc.  Why does DSO waste so much memory? I thought DSO would mean
> all processes share the resident copy of the perl library?

I'm speaking through my hat for a couple of reasons.
a) I've never used DSO
b) I don't know that much about your configuration.

1) if mod_perl isn't loaded by the parent apache process, then every time
it gets loaded by a child process, the memory consumed by mod_perl itself
is _not_ shared. (it's possible the actual code [text segment] might be
shared, but any data structures etc will not be -- dynamic linking is
not my cup of tea).

2) if you had (and it sounds like I was wrong,) one parent daemon handling
the requests for 100 virtual servers, then on average you'd have 100 times
as many child processes as needed for 'just' the mod_perl site. That also
means that your scripts are compiled and cached in 100 times more daemons
than needed, and conversely (same issue, different angle), you are 100
times _less_ likely to find that your script has already been compiled
when you hit a given page.

Hopefully someone on the list can provide the definative answers, lord
knows this is one list that still has a high Guru/beginner ratio ;-) And
the debian fellow debugging the DSO trouble sounded Knowledgable :-)

> >it strikes me that you _want_ a frontend proxy to feed your requests to
> >the smallest number of backend daemons which are most likely to already
> >have compiled your scripts. This saves memory and CPU, while simplifying
> >the configuration, and of course, for a dedicated backend daemon, DSO buys
> >nothing... even if that daemon uses access handlers, it still always needs
> >mod_perl
> 
> remember we're talking an entire ISP, not just a website. I think it might
> be a mighty pain to have everyone running or sharing some backend mod_perl
> server. Logs and all that.

Huh? The same techniques used to separate the logs for the frontend
server(s) can be used to split the backend logs, if you even use any log
info other than the error_log from the backend (they would just repeat the
frontend logs).

> >That said, we bought modperl-space.com back when domains suddenly got
> >cheap, but haven't put together a mod_perl package because we really don't
> >know what folks want/are using it for.
> 
> seems like most folks with enough ?? to be using mod_perl are either
> working corporate or have their own hosts and don't have to deal with ISP's
> on the mod_perl issue.  

True.

----------------------------------------------------------------------
tbrown@BareMetal.com   | Drive thy business, or it will drive thee.
http://BareMetal.com/  | - Benjamin Franklin
web hosting since '95  | 

Re: mod_perl virtual web hosting

[Jesse Wolfe <je...@allheal.com>]

At 02:54 PM 4/12/00 -0700, Tom Brown wrote:
>On Wed, 12 Apr 2000, Jesse Wolfe wrote:
>
>> I am working with www.superb.net to get their mod_perl up and working
>> again. They have great infrastrucure, lots of great tools, and an amazing
>> price.
>> They had apache/mod_perl for awhile, and upgrades broke it.  I expect they
>> will have it in a week or two, if we can use all these dynamic/shared
>> modules as planned. 
>
>strikes me (as an owner of a web hosting service) that DSO is the wrong
>answer. What does DSO buy you? NOTHING except a complete waste of
>memory... 

well, it would let each customer add their own combo of modules to their
apache server without requiring either two installs (one with, one without
mod_perl) or making everyone's server run mod_perl even if they aren't
using it.

But it is a good question... I found it kind of unusual to request that
EVERY Apache module be dso, including mod_perl, mod_ssl, PHP3, and libdav.
I'm not even sure that it's possible that it will run well. Any advise
anyone has here would be most appreciated.

I'm actually kind of surprised I got mod_perl DSO 'make test' to pass at all.

>
>I'm reading between the lines here, but it sounds like you are trying to
>have _one_ parent apache daemon that services _everything_ on the machine
>(likely _more_ than one website), which would imply that you are going to
>have an _extremely_ low hit ratio on your mod_perl scripts.

nahh, that's not where we were going with it. I am pretty sure it's just a
"maximum flexibility" feature they want to have on hand to minimize tech
support, etc.  Why does DSO waste so much memory? I thought DSO would mean
all processes share the resident copy of the perl library?

>
>it strikes me that you _want_ a frontend proxy to feed your requests to
>the smallest number of backend daemons which are most likely to already
>have compiled your scripts. This saves memory and CPU, while simplifying
>the configuration, and of course, for a dedicated backend daemon, DSO buys
>nothing... even if that daemon uses access handlers, it still always needs
>mod_perl

remember we're talking an entire ISP, not just a website. I think it might
be a mighty pain to have everyone running or sharing some backend mod_perl
server. Logs and all that.

>
>That said, we bought modperl-space.com back when domains suddenly got
>cheap, but haven't put together a mod_perl package because we really don't
>know what folks want/are using it for.

seems like most folks with enough ?? to be using mod_perl are either
working corporate or have their own hosts and don't have to deal with ISP's
on the mod_perl issue.  With all this talk about mod_perl programmers being
needed, I'm surprised to find so few ISP's offering it.  Bottom line it
seems you need to be able to keep a mod_perl guru on hand just to keep it
going... the compilation, etc. of it is so complex. I actually need to
leave my original mod_perl isp because they just don't have the staff to
make the right mods to their system, even if I figure it out for them.
Their mod_perl person got up and left and they can't seem to hire a
replacement. Anyone in Boston area would like to work with a pretty decent
ISP?

Regards,

Jesse

Re: mod_perl virtual web hosting

[Tom Brown <tb...@baremetal.com>]

On Wed, 12 Apr 2000, Jesse Wolfe wrote:

> I am working with www.superb.net to get their mod_perl up and working
> again. They have great infrastrucure, lots of great tools, and an amazing
> price.
> They had apache/mod_perl for awhile, and upgrades broke it.  I expect they
> will have it in a week or two, if we can use all these dynamic/shared
> modules as planned. 

strikes me (as an owner of a web hosting service) that DSO is the wrong
answer. What does DSO buy you? NOTHING except a complete waste of
memory... 

I'm reading between the lines here, but it sounds like you are trying to
have _one_ parent apache daemon that services _everything_ on the machine
(likely _more_ than one website), which would imply that you are going to
have an _extremely_ low hit ratio on your mod_perl scripts.

it strikes me that you _want_ a frontend proxy to feed your requests to
the smallest number of backend daemons which are most likely to already
have compiled your scripts. This saves memory and CPU, while simplifying
the configuration, and of course, for a dedicated backend daemon, DSO buys
nothing... even if that daemon uses access handlers, it still always needs
mod_perl

That said, we bought modperl-space.com back when domains suddenly got
cheap, but haven't put together a mod_perl package because we really don't
know what folks want/are using it for.

> 
> I'm moving my mod-perl project there once I get it going. Have you checked
> out the list on perl.apache.org's documentation?
> 
> Jesse
> 
> 
> At 01:26 PM 4/12/00 -0400, Gagan Prakash wrote:
> >Hello,
> >
> >I have been looking for mod_perl virtual web hosting companies who have fast
> >servers and good infrastructure but the two I have found so far have either
> >had problems with their mod_perl setups (they installed the module, did not
> >change apache configs or changed them incorrectly) or have been very slow.
> >These two are www.123hostme.com or www.olm.net.

last I heard, olm.net treated their resellers well, but their
tech support to direct clients was supposed to be pretty poor.

> >
> >I would greatly appreciate if somebody could point me in a better direction.
> >
> >Thanks
> >Gagan

----------------------------------------------------------------------
tbrown@BareMetal.com   | Drive thy business, or it will drive thee.
http://BareMetal.com/  | - Benjamin Franklin
web hosting since '95  |