On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
> Modperlers...,
>
> I'd like to start a discussion about the deficiences in Apache/modperl
> and get you feedback with regard to this issue. The problem as I see
> it is that the process model that Apache uses is very hard on modperl.
mod_perl-2.0/apache-2.0 should solve this (fingers crossed :)
> 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.
with 2.0, the syntax tree is shared (at the Perl level)
however, padlists are not shared. as i mentioned, i'd like to look at
using your "garbage collector" for 2.0. if it could run in it's own
thread and examine the padlists of idle interpreters, it could be big win.
i wouldn't want it to release all allocations in the padlist by default.
maybe be configurable to only release things of a certain size. what i
would personally like to see is one that just reports anything that's
larger than X size, so i can fix the Perl code not copy large chunks of
data, and/or figure out how to make large chunks of data shared between
interpreters. i kinda started this with the B::Size hooks in
Apache::Status, but you have to dig around the symbol table to find how
big things are, there's no overall reporting mechanism.
> One of my concerns is that maybe the apache module API is simply too
> complex to pull something like this off. I don't know, but it seems
> like it should be able to handle something like this.
if you need a model where the Perl engine is in a different process
than Apache, that should be implemented with FastCGI or something else.
the overhead of passing the request_rec (and everything it points to)
between processes for all of the various phases (so mod_perl could
still everything it can today) would be a nightmare.
