httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: Multi Language Error Documents
Date Mon, 20 Aug 2001 04:40:17 GMT
On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:

> From: "Marc Slemko" <marcs@znep.com>
> Sent: Sunday, August 19, 2001 9:23 PM
> 
> 
> > On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:
> > 
> > > 4. Change the default document list to serve index.html index.html.var in that
order.
> > >    This will shortcut a ton of time negotating the content by stat() calls,
since
> > >    without Multiviews we won't look for index.html.*, but we will catch the
typemap :)
> > 
> > Note that this doesn't work when people do silly things like use
> > "/index.html" instead of "/".  Typically many people creating content use
> > the two interchangeably.  But that's ok, I think... since random people
> > shouldn't be making documents linking to the default index page.  
> > Although we should perhaps make sure there are no silly links in the docs
> > that reference /index.html.
> > 
> > Hrm.  When you committed the DirectoryIndex change, you did .html.var
> > first then .html.  Shouldn't it be the other way around (like you stated
> > above)?  In the current order, if someone sticks there own index.html in
> > there, it will not behave entirely as expected in odd (to the user)
> > ways...
> 
> 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.

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?

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

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.

> > 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.

> 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.


Mime
View raw message