> >
> >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.
----------------------------------------------------------------------
[EMAIL PROTECTED] | Drive thy business, or it will drive thee.
http://BareMetal.com/ | - Benjamin Franklin
web hosting since '95 |
