hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HTTP Core Performance and Reactor Buffer Size
Date Sun, 24 Nov 2013 13:21:23 GMT
On Sun, 2013-11-24 at 14:15 +0100, Andreas Veithen wrote:
> Instead of taking 40 seconds, the scenario now takes 20 seconds, with the
> request processing completing in less than a second. So there is still a
> problem, but I didn't get the time yet to debug further. I'll keep you
> updated once I have more information.
> 
> Andreas
> 

I see. As said in my previous message messing with OS default settings
for RCV/SND buffer size seems to cause only grief. 8K for RCV buffer
sounds way too small.

Oleg

> On Sunday, November 24, 2013, Oleg Kalnichevski wrote:
> 
> > On Sun, 2013-11-24 at 13:02 +0100, Andreas Veithen wrote:
> > > All,
> > >
> > > While debugging this scenario (on Ubuntu with the default receive
> > > buffer size of 8192 and a payload of 1M), I noticed something else.
> > > Very early in the test execution, there are TCP retransmissions from
> > > the client to Synapse. This is of course weird and should not happen.
> > > While trying to understand why that occurs, I noticed that the TCP
> > > window size advertised by Synapse to the client is initially 43690,
> > > and then drops gradually to 8192. The latter value is expected because
> > > it corresponds to the receive buffer size. The question is why the TCP
> > > window is initially 43690.
> > >
> > > It turns out that this is because httpcore-nio sets the receive buffer
> > > size only on the sockets for new incoming connections (in
> > > AbstractMultiworkerIOReactor#prepareSocket), but not on the server
> > > socket itself [1]. Since the initial TCP window size is advertised in
> > > the SYN/ACK packet before the connection is accepted (and httpcore-nio
> > > gets a chance to set the receive buffer size), it will be the default
> > > receive buffer size, not 8192.
> > >
> > > To fix this, I modified httpcore-nio as follows:
> > >
> > > Index:
> > httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> > > ===================================================================
> > > ---
> > httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> > > (revision 1544958)
> > > +++
> > httpcore-nio/src/main/java/org/apache/http/impl/nio/reactor/DefaultListeningIOReactor.java
> > > (working copy)
> > > @@ -233,6 +233,9 @@
> > >              try {
> > >                  final ServerSocket socket = serverChannel.socket();
> > >                  socket.setReuseAddress(this.config.isSoReuseAddress());
> > > +                if (this.config.getRcvBufSize() > 0) {
> > > +
> >  socket.setReceiveBufferSize(this.config.getRcvBufSize());
> > > +                }
> > >                  serverChannel.configureBlocking(false);
> > >                  socket.bind(address);
> > >              } catch (final IOException ex) {
> > >
> > > This fixes the TCP window and retransmission problem, and it also
> > > appears to fix half of the overall issue: now transmitting the 1M
> > > request payload only takes a few 100 milliseconds instead of 20
> > > seconds. However, the issue still exists in the return path.
> > >
> > > Andreas
> > >
> >
> > Andreas
> >
> > I committed the patch to SVN trunk. Please review.
> >
> > Could you please elaborate what do you mean by 'issue still exists in
> > the return path'. I am not sure I quite understand.
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org <javascript:;>
> > For additional commands, e-mail: dev-help@synapse.apache.org<javascript:;>
> >
> >



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message