httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Multi Language Error Documents
Date Mon, 20 Aug 2001 04:51:27 GMT
From: "Marc Slemko" <>
Sent: Sunday, August 19, 2001 11:40 PM

> On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:
> > When I proposed it, I blew it.  I agree it might be 'unexpected' unless we document
> > it well, but we have a basic problem.  If we go index.html -> index.html.var,
we get
> > an extra stat.  Worse, we may (if they've toggle multiviews themselves) end up walking
> > the multiview search, and then finding the .var which toggles it's own negotation.
> Neither of those matter though.  An extra stat() in the default
> configuration when hitting the default page, that will almost
> certainly go away when content is put up by the user, is irrelevant.

Ok... if we can find index.html, I suppose that we serve it over index.html.var
in htdocs.  Feel free to commit a patch :)

> Look at it this way: if you have .html.var then .html, every other
> request is going to have an extra stat().  Which is more common: a .var
> file being there, or a .var file not being there?

Agreed :)

> If they enable multiviews... well, then we just have to trust what they
> are doing.

I don't, but this is a 'play' site anyways.

> I just think that the reality is users will take the default install,
> and start adding their content.  So the configuration should be 
> tuned around that.

Fair enough.  I'd still like to 'recommend' they create their own web tree and point our
htdocs to that directory.  I believe the /manual alias helps them do that.

> > > So I like the idea of using a type map so multiviews don't have to be
> > > enabled for "/".  The performance for / requests will still be
> > 
> > ??? pretty fast.  We have another issue.  We need to stop stat'ing to get file sizes.
> It is pretty fast, but nowhere near fast as serving non-negotiated
> static content will be once the code path is optimized.  But it is 
> "fast enough", since performance only matters in certain contexts.

Just remember.  The average 'joe user' who is doing a benchmark just compares;

and sees what happens when they toggle servers :)

> > It's bogus.  Heck, SSI and CGI are generally 'smaller' than precomposed pages. 
> > I sure don't think they save us a thing.  Testing the size wastes more cpu than
> > serving our first best match.  Once that is done, this should be _very_ optimal.
> You still have to open and parse an extra file and take a fair hit
> due to decreased locality of reference, etc.  But again, that's
> ok, since performance is not the number one criteria for the default
> index page.

Want to bet :-?  I still argue that "Size Doesn't Matter" :)  Not in negotated content
at least.  I say draw straws.


View raw message