On Fri, Mar 18, 2005 at 09:00:59AM -0800, Justin Erenkrantz wrote: > --On Friday, March 18, 2005 4:34 PM +0000 Colm MacCarthaigh > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
