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



Reply via email to