Gunther- (What follows is some servlet talk... and anyone interested
in a mod_perl garbage collector?)
> If you want the ultimate in clean models, you may want to consider coding
> in Java Servlets. It tends to be longer to write Java than Perl, but it's
> much cleaner as all memory is shared and thread-pooling libraries do exist
> to restrict 1-thread (or few threads) per CPU (or the request is blocked)
> type of situation.
This is sorta OT in this present thread... however. I'm not so sure
about your statement that Java apps take longer. My experience is the
opposite. (And I have quite a lot of experience in writing servlets)
However, your next comment hits the nail on the head... buggy, and one
script blown kills the entire engine. Not only that, but if memory
usage spikes over the memory setting you used when starting the engine
the whole thing blows up in your face. (Basically new instances of
requests for servlets get messed up) The whole memory issue with java
is almost worst... although with competent admining it can be "not too
bad". Then of course theres the speed issue with java... though
TowerJ would fix this up nicely :-).
>
> However, I would stress that speed/threading is not the only name in the
> game. Reliability is another concern. Frankly, I have seen a lot of buggy
> servlets crash the entire servlet engine making a web site useless.
> Generally if there is a core dump in an Apache/Mod_perl process, the worst
> is that one request got hosed.
Gotta love that! :). Well... I've seen a little worse, but not much.
Doesn't touch the problems you can have with JServ and kin. Once I
had a really mission critical JServ engine die, and went on a
vacation... it didn't get back up until I got back. This put JServ on
the non-use place in my book. You really need 24hr
staffing/notification to use a servlet engine... major bummer.
>
> I am resigned to the fact that all languages are buggy, and so I like
> engineering architectures that support buggy languages (as well as buggy
> app code).
Hehe... the essential problem with modperl comes down to this...
Garbage collector?...??? Nope... it's not there. I've written a real
basic garbage collector that might be able to be adapted to modperl.
Okay... now here goes:
The problem...: The way the perl garbage collector works is there
is a reference count for each variable on the stack. There are
different types of variables, but basically two types: "my'd"
lexicals, and those that are not :-). (There is the local() stuff
too, but that's just stack manipulation of non-my'd type)
Basically within the structure of mod_perl almost every variable you
actually use is of the lexical variety. Lexical variables are stored
within the CV of whatever package your working with. There is an AV
(Array value) of AV's within that CV that stores all the lexicals.
The first AV within the variable AV stores the name of the variable.
The rest of the AV's under that store the variable value for various
levels of recursion. Now with modperl the Perl garbage collector is
NEVER used. Because the reference count of those variables is never
decremented... it's because it's all in the registry, and it's hard to
tell... hmm... what should I throw away, and what should I keep? ;-).
This contributes to a good deal of speed... because you hardly EVER
have to create more instances of variables after running the program
for the first time. It's all stored in memory... wow, that's
GREAT!... not. Well, it is, but basically it sucks up tons and tons
of memory. This is why that requiring the scripts before fork;ing can
be okay, but not great, because each process still has to store all
these stack variables again for every "package/script" within
mod_perl. Now... I could see a couple solutions.
1) "Smartly" route script requests to the appropriate set of apache
instances. So basically not every apache instance would have to store
the variable and code info for every script that has to be run.
2) Make a garbage collector for modperl. This would be pretty cool...
but programmatically it's really really hard. And there is no
guarantee that the whole variable design would change in the future
releases of perl. I could see a garbage collector that killed the
values within the stack, and wiped out totally the existance of
recursive layers. I'm fully onboard with submitting my code and
helping out if someone besides me is interested in this. (I don't
have time to do it solo... besides I need someone to bounce ideas off
of. This is a really hard thing to do, and it would be pretty easy to
break a lot of stuff in the process of building this.) The use of a
garbage collector would have several benefits... it would get rid of
the "security hole" that I percieve in mod_perl. It would also lower
the process overhead... and generally be really cool.
(BTW: If anyone that knows the internals of mod_perl is seriously
interested in working on a garbage colector, drop me an email and
we'll talk about it. I'm pretty interested in doing this. You don't
have to know a lot of perl internals, but you would have to understand
the c code in mod_perl fairly well.)
Or... do both! :).
Thanks,
Shane.
>
> Later,
> Gunther
>
> __________________________________________________
> Gunther Birznieks ([EMAIL PROTECTED])
> Extropia - The Web Technology Company
> http://www.extropia.com/
>
