apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm MacCarthaigh <c...@stdlib.net>
Subject Re: do we still want sendfile enabled with our default conf files?
Date Fri, 18 Mar 2005 17:18:17 GMT
On Fri, Mar 18, 2005 at 09:00:59AM -0800, Justin Erenkrantz wrote:
> --On Friday, March 18, 2005 4:34 PM +0000 Colm MacCarthaigh 
> <colm@stdlib.net> wrote:
> 
> >In my experience, more users are brain-dead than OS's ;) Surely it's the
> >users who don't have a hope of diagnosing the kinds of intermittent 
> >problems
> >that using sendfile can trigger who should be kept in mind?
> >
> >Users whose performance requirements are such that they will benefit
> >from the use of Sendfile will find it, it's not like the option would
> >dissapear. Even more so if it left on in the high performance config.
> 
> The issue is that the APR developers can assist in this by using our 
> knowledge of when it is safe to use sendfile() or not.  We should not be 
> tasking administrators with this responsibility. 

I disagree. I think the reality of the bugs we are dealing with tasks
administrators with this responsibility. Whether or not an administrator
chooses to host their content on a network mount for example - is
clearly an administrative decision, and it's not so easily detectable by
APR.

Your own arguments are that people who can benefit from the power of
sendfile should be able to. An admin on Linux who uses ext2/3 should be
able to, so having a niaive "if (linux) no_sendfile" is far too
unwieldly, and the logic for testing support filesystems and so on would
be pretty exhaustive and might even hamper any benefits of using
sendfile in the first place.

>  I abhor knobs that have 
> to be turned on in order for the system to work to the best of its ability. 

Default values are never about working a system to the best of its
ability. Surely, they are about working correctly and reliably. Any
number of changes can be made to a httpd conf to speed things up, and
they are always going to require the knowledge of the system
administrator. How is this any different?

> It's bad behavior on our part: we shouldn't need a 'high performance 
> config'.  If we do, then it means that the portability layer failed.

It's all about trade-offs. Turning off overrides means no stats for
.htaccess, that's a performance increase in one sense, but it's a
feature-loss in another. Turning on Mmap can boost throughput, but make
you use more memory  or reduce reliability with multiple CPU's or
network shares - who decides which is better performance? Having more
children means you can handle more clients more quickly, but it might
increase the load on your machine - who decides which is a performance
increase?

Enabling Sendfile might get you better throughput, with less CPU/Memory
usage, but then again it might mean you serve files less reliably.  Who
decides if this is a performance increase?

> Therefore, we can make it such that the httpd's default configuration does 
> the right thing a heck of a lot more often than it does now.  And, if that 
> means we disable sendfile() across the board on more platforms - so be it.  

I think that runs contra to your own logic about wanting people who
should be be able to benefit from it to do so.

I think it's just one of those cases where it would be highly
non-trivial and inefficient to put all of the checks in APR, simply due
to the real-world nature of the bugs, but that at the same time there is
a clear benefit available to those willing to take the time to read the
manual and decide for themselves if it will work in their situation.

-- 
Colm MacCárthaigh                        Public Key: colm+pgp@stdlib.net

Mime
View raw message