httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: PR & 1.1b1
Date Tue, 19 Mar 1996 18:31:02 GMT
> 
> In reply to Ben Laurie who said
> > 
> > > Hmm, I've never quite followed the tradeoffs between the different models
> > > used for web servers. Someone want to enlighten me with brief list of
> > > pro's and con's.
> > 
> > A list of disadvantages:
> > 
> > 1. Forking: Context switches, and non-shared resources.
> > 
> > 2. Multithreading: Lightweight context switches, semaphores, locking etc.
> > 
> > 3. Singlethreading: Stateful program model.
> 
> Umm, that wasn't really what I meant, I know what the difference
> between forking and non-forking servers are! What I wanted to know is
> what the tradeoffs for web servers would be. i.e. is a fork a large
> overhead in terms of serving a request etc. I assume there's some data
> of some sort on these issues since the consensus seems to be that single-
> threaded servers provide better performance and I'm a bit puzzled as to
> how given that requests will be queued. On the other-hand a single *process*
> server that is multi-threaded would clearly be quicker than a pre-forking
> server such as Apache because of the lower context switching overhead. A lot
> of this also depends on the overhead imposed by the underlying OS, clearly
> a threaded kernel (such as SunOS) and a threaded server are going to sit
> well together on a dedicated httpd box where LWP in the kernel allow for
> fast context switching for incoming requests. Whereas a threaded server
> on FreeBSD isn't going to gain you as much since you'd have to fake the
> LWP in a single process, although that may still be faster than a real
> context switch between children. Anyway, some figures and opinion on these
> specifics was more what I was after.
> 
>  
> > > What is this API supposed to achieve? I don't understand why the API would
> > > be overly affected at this stage, surely the first thing to decide is
> > > what functionality the API should provide?
> > 
> > If it is singlethreaded, the API needs support for input/output "ready",
> > things to wait for in select() and so on. Like the program, the API is inside
> > out.
> 
> I don't think the protocol API should be tied to the lower level implementation
> of the process model. You should have a common API that can be used in both
> cases so that the protocol handlers can be written independantly of the
> process model.
> 
> There would be a "listener" process of some sort that received data from
> the socket and farmed it out to the appropriate handler for that protocol.
> There would need to be an API for the protocol to access information from
> the server and that's what we need to start thinking about independantly of
> the underlying process model. i.e. what does a protocol handler do and what
> data does it require to handle it. Protocol handlers would obviously have
> to register with this listening process. Only the listening process would
> have to be concerned with the underlying model and in itself would not really
> be part of the protocol API.

I think we have a basic misunderstanding here. When I say singlethreading, I
don't mean handle one request then handle the next. I mean do a lot of
select()ing, partial reads, partial writes and so forth. So requests are
handled concurrently but without the use of threads.

In this model, time consuming processes are usually handled by subprocesses,
so they don't delay the main process. Of course, all these partial reads and
writes mean that each "thread" (not a real thread, remember) has to carry a
lot of state with it. On the other hand, it generally doesn't need to have any
truck with semaphores and so forth.

The completely different mode of execution also means a different API (more
along the lines of "I'm ready to send something, have you got anything to
send?" rather than "Send this when you can (and block me in the meantime)").
Inside out, in short.

So, really, there are 4 kinds of server, the 4th being Apache limited to a
single process - clearly undesirable.

As to what the API has to do - I'm not avoiding the question, just deferring
it, as David Robinson and I pretty much thrashed that out already, I just have
to find the document...

> 
> > > Ohh, and I'll switch the C++ thing around, why do you think it will be
> > > any better?
> > 
> > Also, there are some general benefits:
> > 
> > 1. Strong type checking.
> 
> Ok, I'll concede that one.
> 
> The other points I don't agree with since I can do them all in a well
> understood manner in C without worrying about all the other OO stuff
> that C++ brings into the picture.
> 
> This thread is getting religious, let's forget the C vs C++ debate
> since I suspect the overriding factor will be that not as many people
> program in C++ regularly (me included) so we'd be short of developers.

Interesting how C++'s biggest detractors are those who haven't learnt it
properly. I defy you to produce a neat equivalent of a pure virtual function
or an overloaded function in C. Operators, of course, you can forget.

I do agree with your suspicion. I might write a C++ wrapper instead, so those
who can do C++ can use it.

Cheers,

Ben.

> 
> -- 
>   Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
>   Elsevier Science TIS online journal project.
>   Email: p.richards@elsevier.co.uk
>   Phone: 0370 462071 (Mobile), +44 (0)1865 843155

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Mime
View raw message