httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: cvs commit: httpd-2.0 CHANGES
Date Wed, 13 Jun 2001 16:14:50 GMT
From: "Greg Ames" <>
Sent: Wednesday, June 13, 2001 9:56 AM

> Cliff Woolley wrote:
> > > How huge are 20 apr_mmap_t's?  Big deal if they have to wait for the end
> > > of the request.  and how common would it be to have 20 include files
> > > anyway?
> > 
> > Yeah, but there're other problems, like chewing up too many file handles
> > in pathological cases...

Either way, you are chewing up system handles like they are going out of style.
Most OS's optimize for the 'appropriate' working set, appropriate being defined
by demand.  This sort of spikey behavior will circumvent any kernel optimization.

> > > Let's see some real world examples where this is noticeably bad.
> > 
> > What about mod_autoindex on a directory with 1000 files?
> <gulp>  If the little icons on each line turn into subrequests, you've
> got me, for sure.  

No.  Each file in the directory becomes it's own little temporary subrequest,
to determine if would be served.  We do this to assure that no file is included
which wouldn't then be passable.  So, we have 1000 subrequests testing for the
validity of the file, and this drops out the .htpasswd, .htaccess, and the
restricted subdirectories.

Each one isn't bad, until you stop freeing them.

The li'l icons themselves?  They are just seperate requests (pipelined, kept alive
and/or browser cached, we hope :-) 

> I don't think many admins would intentionally turn on autoindexing on
> such a directory - imagine navigating thru this puppy with your favorite
> browser.  But if they did, I'm sure that they would rather see output
> than seg faults.

And this is a ticket to segfaults.

> As I think I said, I don't mind a superior solution.  But the last time
> I checked, it didn't exist.  Seg faults in the core whenever you use
> something as popular as mod_include just don't cut it.

No, they don't.  Glad others are already hacking out the correct setaside logic.

I tend to agree with (Dean? Roy?) here ... drag the last 500 bytes from the bucket,
or just send the dang thing down the wire.  I'd be happier with a patch that says,
"hmmm... sendfile buckets are basically broken, let's dump it on the wire rather
than setting it aside", and close this bug in favor of poorer performance at this
moment.  Fix the sendfile bucket and revert that logic, and we get the performance
back later on.


View raw message