From: "Marc Slemko" <[EMAIL PROTECTED]>
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;
http://www.server.com/
and sees what happens when they toggle servers :)
> > It's bogus. Heck, SSI and CGI are generally 'smaller' than precomposed pages. But
> > I sure don't think they save us a thing. Testing the size wastes more cpu than
>just
> > 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.
Bill
