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
