httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wouters <tho...@xs4all.net>
Subject Re: ETags & NFS caches (Apache 1.3)
Date Fri, 27 Oct 2000 09:12:14 GMT
On Fri, Oct 27, 2000 at 01:05:53AM +0100, James Sutherland wrote:
> On Fri, 27 Oct 2000, Thomas Wouters wrote:
> 
> > On Thu, Oct 26, 2000 at 02:02:45PM -0700, Koen Holtman wrote:
> > 
> > > I recall having an exchange about strong etags based on the unix ctime vs.
> > > NFS on the http-wg mailing list.  Jeff Mogul, who is some kind of NFS guru
> > > in another life, told me that NFS makes no hard guarantees about file
> > > ctimes always changing as soon as the contents change.  So this seems to
> > > be an NFS 'feature' not accounted for by Apache.
> > 
> > Yeah, I have some vague recollections regarding that as well. Something like
> > data being cached, but not meta-data/file-properties. 
> 
> Hrm... I'll have a word with the Unix systems people here. We do some
> pretty brutal things to poor unsuspecting little NetApp filers - and the

The problem isn't load on the filer. In fact, the load on the filer is
extraordinarly low :) We've done some brutal assault as well, when we had
both our mailspool and our home directories on the same F720, which would
then crap out when we started running 'dump' remotely, but never saw
something like this. And the filer we are using for www.startpagina.nl is an
older F330 that does little else. If the problem is the filer, which is
still possible, it's probably caused by the huge number of requests for a
limited number of files.... or something. None of the less frequently
accessed files show this problem, even though 'less frequently' here is
still a respectable frequency for any website :)

(The low load on the F330 is a clear indication that BSDI is doing massive
caching, though. The weird thing remains that Apache doesn't see a change
until some other process accesses the file. Really strange.)

> Another possibility: is the OS skipping the open() call from Apache (since
> the file was just opened), but handling it properly when another process
> makes it? Remember access control checks etc. are made on open(); if BSDI
> were wrongly caching this for repeated open() calls from a single process,
> that could explain the problem.

Yes. I'm going to install the weak etag thing today, just so the site can
function a tad better, and then do some things like running ktrace on an
apache process (ktrace is BSDI's form of strace, but less useful), trying to
grok BSDI kernel and libc code, and trying to reproduce it on another box,
by doing all the requests ourselves. Not being able to test except on the
main pages on a high-profile site doesn't really help at debugging :)

[ weak etags might fix things ]

> While it would be nice (for you) to avoid the problem like that, getting
> Apache (or BSDI??) fixed properly would be preferable IMO :-)

Of course, but I doubt it's something Apache can fix, without creating
digests for every single request. I'm thinking it's flawed logic in the BSDI
libc, something like 

    if file in fd_cache and last_access(file) < 100ns_ago:
        last_access(file) = now
        return fd_cache[file]

but which somehow only gets triggered in severe edge cases. Don't ask me why
it isn't showing in anything but apache, though :-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

Mime
View raw message