On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
> > > 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?
>
> Yep very handily I might add ;-). Basically phhttpd is not process
> based, it's threaded based. Which means that everything is running
> inside of the same address space. Which means 100% sharing except for
> the present local stack of variables... which is very minimal. In
> terms of the perl thing... when you look at your processes and see all
> that non-shared memory, most of that is stack variables. Now most
> webservers are running on single processor machines, so they get no
> benefit from having 10s or even 100s of copies of these perl stack
> variables. Its much more efficient to have a single process handle
> all the perl requests. On a multiprocessor box that single process
> could have multiple threads in order to take advantage of the
> processors. See..., mod_perl stores the stack state of every script
> it runs in the apache process... for every script... copies of it,
> many many copies of it. This is not efficient. What would be
> efficient is to have as many threads/processes as you have processors
> for the mod_perl engine. In other words seperate the engine from the
> apache process so that there is never unneccesary stack variables
> being tracked.
I'm not sure you are right by claiming that the best performance will be
achieved when you have a single process/thread per given processor. This
would be true *only* if the nature of your code would be CPU bound.
Unfortunately there are various IO operations and communications with
other components like RDBMS engines, which in turn have their IO as well.
Given that your CPU is idle while the IO operation is under process, you
could use the CPU for processing another request at this time.
Hmm, that's the whole point of the multi-process OS. Unless I
misunderstood your suggestion, what you are offering is a kinda DOS-like
OS where there is only one process that occupies CPU at any given time.
(well, assuming that the rest of the OS essential processes are running
somewhere too in a multi-processes environment.)
______________________________________________________________________
Stas Bekman | JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.org http://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
----------------------------------------------------------------------
