httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Spero <...@mossflower.oit.unc.edu>
Subject Re: Apache 2.0/NSPR
Date Thu, 10 Sep 1998 04:38:47 GMT
On Wed, 9 Sep 1998, Ben Laurie wrote:
> Marc Slemko wrote:
> > On Wed, 9 Sep 1998, Ben Laurie wrote:
> > > Marc Slemko wrote:
> > > > Memory and disk are the same thing.
> > > Bollocks. :-)
> > No, honest.  Especially with modern vm systems, the most efficient way for
> > your application to differentiate can sometimes be to not.
> That I can agree with, so long as we remember the "sometimes". However,
> sometimes it isn't the most efficient. Certainly a pointer is quicker

[just wanted to keep the bollocks. A few disparate points - I screwed up
 my linux box and scattered my mail all over the place.]

1) In the situation we're talking about, disk is most definitely not
memory. The cache subsystem is part of the server kernel- the server has a
far better handle on page replacement policies than BSD or Linux. The
memory cache should be locked; otherwise you can't tune performance at
all.  [And this is coming from me, an object database freak]

2) Layering is dangerous to performance, and should be collapsed as much
as possible. This is part of the job of the middle end.

3) All object access is mediated by the cache. Thus, any sub objects
referenced by another object are cached. (For example, part of the
namespace might wrap objects with headers and footers. The header, footer,
page body and end result would all be cachable). 

4) A lot of the cache could be made kernel resident. This means that  
although cache invalidation can be complicated (objects can have a
validate method), simple tests should be handlable simply and predictably-
for example file modification date, eq checks for negotiation etc.
Otherwise you have to leave the kernel to validate.

5) The cache allows more objects than normal to be treated as files (i.e.
they have finite length, rather than being data streams). This makes it a
lot easier to attach file system protocol front ends to the middle-end
namespace (in particular code from Samba and the old user mode NFS
server). This allows the server to mediate *all* access to the data store,
making it easy to use *active* invalidation, with no validation checks at
all in the fast path.

6) This implies that the namespace model should be mappable in terms of
directories, files, and specials (cgi-scripts, etc). This gives the
hierarchical component of the resolution process a higher priority than
the other phases. 

7) TCP changes: There are several changes that would be useful for a web
server. 
	7.1)The most important of these is probably sharing congestion
	window information between connections to the same host. This
	gives you a lot of the performance win and anti-MARCA congestion
	avoidance of SCP/HTTP-NG. Someone has done this for BSD
	(see end2end )
	7.2) Use shared send window space (you need 1 BDP total for all
	the  sub-connections. This gives you the memory performance of 
	SCP/HTTP-NG (lets you use honking big buffers iff you have that 
	many packets in flight; otherwise, throttle back the server. Not
	known to be implemented ATM (see end2end).
	7.3) Use Zero-copy w/ page flipping. Especially if you have a
	kernel cache. 
	7.4) Allow connect_and_write (send data with syn)
	7.5) Allow accept_and_read( read data with syn, delay syn-ack).
	7.6) Use ultra-aggressive tcb search.

There's more, but I'm sleepy and sick. 

Simon


Mime
View raw message