httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: fix for hybrid server problems.
Date Sun, 09 May 1999 21:41:33 GMT
I was thinking, in order for you guys to better benchmark Apache against
real-world types of stresses (since you obviously don't have high volume
real world servers that you can just play with on a whim) if you could get
a network set up with, say, 8 32-port DigiBoards on 8 low-end Pentium
routers, and putting all the test servers from there, running SLIP from
the serial ports, you could effectively simulate the common long haul
clients.  256 bandwidth constrained clients would be much more like what a
real webserver deals with.

tani hosokawa
river styx internet

On Sun, 9 May 1999, Dean Gaudet wrote:

> On Sun, 9 May 1999, Manoj Kasichainula wrote:
> > My understanding is that a select()-based server is fast because you
>                                                    ^^
> > don't have to deal with many context switches, right?
> s/is/can be/
> > In this case though, we have at least 1 forced context switch for
> > every connection (to pass a new connection to a worker thread). And
> > for the slightly big files, we have to jump back to the event thread
> > and back again to a worker thread for logging.
> > 
> > With long files, you avoid the context switching between threads as
> > they write out the data, but couldn't this be largely eliminated with
> > mmap+write or sendfile() anyway?
> I care less about static benchmark tests on local networks with no latency
> than I do about real life web sites with loads of long haul, slow clients,
> downloading large files consuming an expensive resource:  a thread slot
> and stack.
> It's one of those cases where my opinion is that the wins are in
> real-world useability, and correctness (so far it looks like the best
> solution for the graceful stuff) and the cost might be a modicum of
> performance loss on static localnet benchmarks. 
> Also, this helps keep-alive connections.  We could plop connections back
> up to the event-thread to wait for any more input... rather than consuming
> a thread for 15s...
> We can make the cutoff point different if you're concerned over the extra
> context switches... but really -- for responses over SO_SNDBUF, the worker
> thread has to block at least once.  It may as well pass the work to the
> event-thread to be aggregated with other similar work before blocking. 
> What would be extra cool would be LIFO semantics on threads trying to
> dequeue from the request queue -- if we could service multiple requests in
> one time slice on one thread that would be way nice.
> So far my largest concern, which is the same as my concern with entirely
> select-based servers, is disk i/o.  This all works wonderfully if you
> rarely have to page from disk.  But for servers with large working sets,
> aggregating like this hurts because you have only a single i/o request
> outstanding at a time... with multiple processes we alleviate some of this
> problem... there are probably other options -- but I think this is
> something we can deal with when we get there. 
> Dean

View raw message