hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: HTTP Core Performance and Reactor Buffer Size
Date Sun, 24 Nov 2013 16:40:30 GMT
On Sun, Nov 24, 2013 at 2:21 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
> 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.

Well, it causes grief because httpcore-nio doesn't set the receive
buffer size at the right moment. That being said, I agree that 8K
sounds too small.

What I still don't understand completely is why this causes such a
slowdown. The effect of the issue in httpcore-nio is that the peer
sees the TCP window size gradually drop from 43690 to 8192. Would that
trigger some mechanism in the TCP stack of the peer that delays the
transmission of TCP segments (even if the window is not 0)?

Andreas

> 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@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>

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


Mime
View raw message