Justin,
On Tue, Apr 25, 2000 at 11:26:00PM -0400, [EMAIL PROTECTED] wrote:
> On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
> >
> > > It is very memory inneffecient basically. Each process of apache has
> > > it's registry which holds the compiled perl scripts in..., a copy of
> > > each for each process. This has become an issue for one of the
> > > companies that I work for, and I noted from monitoring the list that
> > > some people have apache processes that are upwards of 25Megs, which is
> > > frankly ridiculous.
> >
>
> Originally I thought this as well.. but, using mod_rewrite, the ratio
> of heavy to light processes can be very high.. some solid figures here:
> our site (dslreports) now handles 200,000 pages a day, every single one
> of them is dynamically generated.. at peak this is 10-20 modperl pages
> a second.. to handle this, we have httpd modperl with MIN, MAX
> and LIMIT of just 8(!) modperl processes, 2 php httpds (just for true type
> font rendering ;-) and as many front-end httpds (mod_rewrite and mod_proxy)
> as required (usually about 100 but can be 200-300 at times). There is
> almost never all 8 modperls running at one time.. even long pages fit
> in the buffers between back end, mod_proxy, and front end meaning its
> hard to catch mod perl in the act of actually servicing requests.
Yes... mod_proxy is the "right way" to really get any sort of serious
stuff hapening in terms of speed. With mod_proxy you really only need
a few mod_perl processes because no longer is the mod_perl ("heavy")
apache process i/o bound. It's now CPU bound. (or should be under
heavy load) Sounds like your ratio is pretty good. (modperl/
mod_proxy) I'd be willing to gamble you could have even less
less mod_perl processes :-).., because they *should* be completely CPU
bound... so really under a "theoretical" machine the optimum number
would be as many processors as you had. But since mod_proxy/mod_perl
communicate through a socket as opposed to shared memory, there is
still a little i/o action. (Which is something I'm thinking about
working on too in mod_proxy..., in local mode allow for more efficient
data transfer methods than sockets) The closer you get to the number
of processors the less context switching involved... although sounds
like you have lots of other stuff running on this box... so this
becomes less of an issue.
> So I find this setup very stable and very flexible .. and would not swap it
> for a pool of interpreters, or a multi-threaded server for all the tea
> in china .. because I dont think either of those models (elegant though
> they may sound, and absolutely the right direction) will be as stable
> for some considerable time.
Hehe... and it is for this exact reason that the actual httpd serving
mechanism hasn't changed much since... well, they started preforking?
Geez... how long ago was that?..., I guess when they started patching
NCSA... so a LONG time ago. I really think it's time... cross
platform is great, but don't hold back other platforms functionality
just to keep the number of macros in the source down... I mean really.
Its sort of a chicken and the egg scenario..., POSIX.4 was put
together some time ago. But it was only implemented in Linux in
2.3.28 or later (or so), well it was in some earlier version, but had
some sort of bug. I think FreeBSD has it too. But theres no pressure
on anyone else to do anything about it because theres no apps. But
theres no apps because theres no OS support... :-)... I hate those
sorts of situations. Who knows when windows will get it? Maybe
Windows 3k.
(I should note, there have been lots of "tweaks" along the way, but
nothing essentially different in concept)
Thanks,
Shane.
>
> -Justin
