httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: do we still want sendfile enabled with our default conf files?
Date Fri, 18 Mar 2005 01:21:31 GMT
On Thu, Mar 17, 2005 at 05:37:38PM +0000, Colm MacCarthaigh wrote:
> On Thu, Mar 17, 2005 at 07:27:54AM -0800, Justin Erenkrantz wrote:
> > These seem like broken OSes and not a suitable justification to disable
> > sendfile.  We should fix the code - perhaps by teaching APR not to enable the
> > sendfile-variants on these buggy platforms - not disable it entirely.  For
> > those platforms that don't have bugs, 
> 
> It's not simply a question of OS bugs. The Linux/IPv6 problem is
> actually a symptom of TCP checksum-offloading bugs in most network
> interface cards. In an effort to speed up sendfile() even more, Linux

Fine, disable sendfile by default with IPv6 sockets on Linux if you are really
concerned that this is an issue.  And, disable it on Win32 by default if
that's a proven problem there as well.

I'd do this by removing EnableSendfile in our default config and having it
default to, indeed, a 'maybe'/'unset' option that allows httpd to make
run-time determinations.  If it is 'on', then we don't second-guess and if it
is 'off', we never use it.

> > disabling sendfile would be a ridiculous performance hit.  -1.  -- justin
> 
> Is there any quantification of this? I'm not entirely convinced of the
> performance hit, mostly - network writes tend to be network-IO bound no
> matter what, and I've yet to see much of a CPU/Memory hit using my own
> benchmarks, with MMap. But I've only run them on Linux and the ammount
> of Ram I have may be distorting the truth of it.

We did performance tests years ago when we added sendfile into the core
(specifically when I added sendfilev from Solaris).  It helped Solaris
at the time on the hardware we had.

Shutting off sendfile means that OSes that are sane and non-buggy have to pay
the penalty and that's absurd.  And, we should not require admins to
specifically tune the machine for optimum performance because a few buggy OSes
and drivers are at fault.  We'd be throwing the baby out with the bathwater
and that's bad.  -- justin

Mime
View raw message