> 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.
I have processes that large, but more than 50% of that is shared through
copy-on-write.
> I wrote a very small perl engine
> for phhttpd that worked within it's threaded paradigm that sucked up a
> neglibible amount of memory which used a very basic version of
> Apache's registry.
Can you explain how this uses less memory than mod_perl doing the same
thing? Was it just that you were using fewer perl interpreters? If so, you
need to improve your use of apache with a multi-server setup. The only way
I could see phttpd really using less memory to do the same work is if you
somehow managed to get perl to share more of its internals in memory. Did
you?
> What I'm
> thinking is essentially we take the perl engine which has the apache
> registry and all the perl symbols etc., and seperate it into it's own
> process which would could be multithreaded (via pthreads) for multiple
> processor boxes. (above 2 this would be beneficial probably) On the
> front side the apache module API would just connect into this other
> process via shared memory pages (shmget et. al), or Unix pipes or
> something like that.
This is how FastCGI, and all the Java servlet runners (JServ, Resin, etc.)
work. The thing is, even if you run the perl interpreters in a
multi-threaded process, it still needs one interpreter per perl thread and I
don't know how much you'd be able to share between them. It might not be
any smaller at all.
My suggestion would be to look at the two-server approach for mod_perl, and
if that doesn't work for you look at FastCGI, and if that doesn't work for
you join the effort to get mod_perl working on Apache 2.0 with a
multi-threaded model. Or just skip the preliminaries and go straight for
the hack value...
- Perrin
