httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: newbie thread/process model question in hybrid server
Date Tue, 06 Jul 1999 11:08:30 GMT

Actually, the argument for a hybrid approach has nothing to do with memory
leak.  That is the argument for a static number of threads.  The argument
for a hybrid server, is reliability.  Threads go down, just like processes
do, but when a thread goes down, so do the rest of the threads in the
process.  I have yet to see an OS that can recover a process when one of
it's threads dies unexpectedly.  If we write a purely threaded server, we
take the chance of having a 3rd party module that seg faults on every
1000th request, taking down the entire server.  With a hybrid approach,
that isn't possible, if we have the same faulty module, we only lose 1/n
requests, where n is the number of processes.

Ryan


On Mon, 5 Jul 1999, Thorsten von Eicken wrote:

> Thanks for clarifying the current hybrid approach. I guess the fact that 
> many thread libs leak memory is a good argument for keeping a hybrid 
> approach as opposed to having the alternative between a pure multiprocess 
> approach and a pure multithreaded approach: restart those processes from 
> time to time as they get too big...
>          Thanks,
>                  Thorsten
> 
> 
> 
> At 10:56 AM 7/5/99 -0400, you wrote:
> >yOn Sat, 3 Jul 1999, Thorsten von Eicken wrote:
> >
> > > I've been reading 2.0/mpm for a couple of days and am still a bit puzzled
> > > by the hybrid server's strategy of using processes and threads. More
> > > precisely, I don't understand why the number of threads per process is
> > > constant and the number of processes varies with load.
> >
> >The reasoning behind this is largely historical.  It was decided to use a
> >variable number of processes, and a fixed number of threads, because it
> >was easier to code, and this was a first draft/prototype.  We also looked
> >at some previous implementations of similar code that tried to grow the
> >thread pool, and most pthread libraries have memory leaks.  When a thread
> >is destroyed, either by itself, or by another thread, it almost always
> >leaves some memory around, and this can get quite large in time.  We were
> >going for a proof of concept, and proff that a hybrid Apache was more
> >scalable.
> >
> >This also would have required a very different scheme for controlling
> >threads/processes.  The parent process really couldn't determine when to
> >tell a process to create a new thread in the current communication model.
> >Dean is trying to solve this problem, but it isn't a problem we wanted to
> >tackle in the first implementation.  We wanted to keep the basic
> >architecture for Apache the same.
> >
> >Ryan
> >
> > >
> > >  From a parallel computing background I would have done the opposite. I
> > > would have expected to set the number of processes to approx the number of
> > > processors in the system, and then used the threads to basically multiplex
> > > one processor. Ideally some affinity between processes and processors 
> > could
> > > be set-up to improve cache behavior. Thus the threads are used to keep
> > > track of the state for the N requests each process has up in the air at a
> > > given time and the processes are used to get parallelism across the
> > > processors of a multiprocessor machine.
> > >
> > > Can a kind soul explain to me how to think about the approach taken in the
> > > hybrid server?
> > >
> > > Thanks,
> > >       Thorsten von Eicken
> > >
> > > ~~~~~
> > > Thorsten von Eicken
> > > expertcity.com                              Phone: (805) 964-0383 x313
> > > 5385 Hollister Ave #111                     Fax:   (805) 964-6103
> > > Santa Barbara, CA 93111                     Cell:  (805) 403-0982
> > >
> >
> >_______________________________________________________________________
> >Ryan Bloom              rbb@raleigh.ibm.com
> >4205 S Miami Blvd
> >RTP, NC 27709           It's a beautiful sight to see good dancers
> >                         doing simple steps.  It's a painful sight to
> >                         see beginners doing complicated patterns.
> 
> ~~~~~
> Thorsten von Eicken
> expertcity.com                              Phone: (805) 964-0383 x313
> 5385 Hollister Ave #111                     Fax:   (805) 964-6103
> Santa Barbara, CA 93111                     Cell:  (805) 403-0982
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message