Re: patches to mod_proxy (was: Re: mod_perl guide corrections)
On Tue, Sep 19, 2000 at 03:24:50PM -0400, Joe Schaefer wrote: On linux, the ext2 filesystem is VERY efficient at buffering filesystem writes (see http://www.tux.org/lkml/#s9-12). If the post data is small ( I don't know what the default size is, but the FILE buffer for the tmpfile is adjustable with setvbuf) it's never written to disk. AFAIK, the only problem with this arrangement for small posts is the extra file descriptor consumed by the apache process. Yeah, I know it's fairly negligible, but I'm not sure the FILE buffer is the one that matters here. If I fwrite(), rewind() and then fread() again, AFAIK libc's stdio still translates this into real kernel write(), lseek(), read() [strace woudl be the final judge here]. From there, the kernel can be smart enough to not actually even touch the disk, but that doesn't work with e.g journaling filesystems which impose stronger sequential conditions on disk writes, or systems like BSD that do synchronous metadata updates. And in any case, you're still doing extra memory copies to and from kernel space. If it was hard to do it otherwise i'd agree with you, but it sounds so simple to keep it in a memory buffer when it's under 16k or some similar limit, that I just think it's much more "obviously right" to do it that way. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: patches to mod_proxy (was: Re: mod_perl guide corrections)
Roger Espel Llima [EMAIL PROTECTED] writes: On Tue, Sep 19, 2000 at 03:24:50PM -0400, Joe Schaefer wrote: On linux, the ext2 filesystem is VERY efficient at buffering filesystem writes (see http://www.tux.org/lkml/#s9-12). If the post data is small ( I don't know what the default size is, but the FILE buffer for the tmpfile is adjustable with setvbuf) it's never written to disk. AFAIK, the only problem with this arrangement for small posts is the extra file descriptor consumed by the apache process. Yeah, I know it's fairly negligible, but I'm not sure the FILE buffer is the one that matters here. If I fwrite(), rewind() and then fread() again, AFAIK libc's stdio still translates this into real kernel write(), lseek(), read() [strace woudl be the final judge here]. From there, the kernel can be smart enough to not actually even touch the disk, but that doesn't work with e.g journaling filesystems which impose stronger sequential conditions on disk writes, or systems like BSD that do synchronous metadata updates. And in any case, you're still doing extra memory copies to and from kernel space. If it was hard to do it otherwise i'd agree with you, but it sounds so simple to keep it in a memory buffer when it's under 16k or some similar limit, that I just think it's much more "obviously right" to do it that way. Sounds good- thanks for the details. How about making a lower limit (for switching from a memory buffer to tmpfile) configurable? Any thoughts on what the directive should be called? -- Joe Schaefer [EMAIL PROTECTED] SunStar Systems, Inc.
