Re: patches to mod_proxy (was: Re: mod_perl guide corrections)

[Roger Espel Llima <es...@iagora.net>]

Joe Schaefer wrote:
> 1) Z requests a dynamic page from A.
> 
> Z -GET 1.1-> A -PROXY-> B -PROXY-> A -CLOSE-> Z
> 
> The current mod_proxy CLOSES the connection from A to Z,
> even if Z requests keepalives, and A implements them.  This
> is bad since subsequent requests for static content (images/stylesheets,etc.)
> will require a new connection.
> 
> The patch should prevent mod_proxy from forcibly closing the 
> A-Z connection.

Sounds good to me.  Does anyone know just why mod_proxy forcibly closes
it by default?  It sounds to me like it would have to actually have
explicit code to forcibly close it, otherwise it woudl be using apache's
generic mechanisms which handle keep-alives...

> 2) Z posts form data that will ultimately be handled by B.
> 
> Z -POST-> A ->PROXY-> B
> 
> Currently, mod_proxy opens the connection to B as soon as it
> determines B is the ultimate destination.  As the POST data 
> is read from Z to A, it is passed along directly to B.  This
> will tie up both A and B if the A-Z connection is slow and/or
> the post data is huge.
> 
> The patch makes mod_proxy buffer the post data in a temp file
> by setting the (new) ProxyPostMax directive to a positive number.
> If the Content-Length header supplied by Z is greater than this
> number, mod_proxy rejects the post request.

Why a temp file?  Maybe I'm particular about this but I don't like
programs writing to temp files and re-reading them for no particular
reason.  Since you're limiting the size anyway, why not just make it a
memory buffer?  Or you could write to a temp file only when it's greater
than some constant (say, 16k), which would let most of your POSTs go
without touching the filesystem.

-- 
Roger Espel Llima, espel@iagora.net
http://www.iagora.com/~espel/index.html

Re: patches to mod_proxy (was: Re: mod_perl guide corrections)

[Joe Schaefer <jo...@sunstarsys.com>]

Roger Espel Llima <es...@iagora.net> 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
joe@sunstarsys.com

SunStar Systems, Inc.

Re: patches to mod_proxy (was: Re: mod_perl guide corrections)

[Roger Espel Llima <es...@iagora.net>]

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, espel@iagora.net
http://www.iagora.com/~espel/index.html

Re: patches to mod_proxy (was: Re: mod_perl guide corrections)

[Joe Schaefer <jo...@sunstarsys.com>]

Roger Espel Llima <es...@iagora.net> writes:

> > The patch makes mod_proxy buffer the post data in a temp file
> > by setting the (new) ProxyPostMax directive to a positive number.
> > If the Content-Length header supplied by Z is greater than this
> > number, mod_proxy rejects the post request.
> 
> Why a temp file?  Maybe I'm particular about this but I don't like
> programs writing to temp files and re-reading them for no particular
> reason.  Since you're limiting the size anyway, why not just make it a
> memory buffer?  Or you could write to a temp file only when it's greater
> than some constant (say, 16k), which would let most of your POSTs go
> without touching the filesystem.

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.  

It might be a good idea to put in a config setting for the FILE buffer size
also- similar to ProxyReceiveBufferSize.

-- 
Joe Schaefer
joe@sunstarsys.com

SunStar Systems, Inc.