hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Wolff <m.wo...@ftapi.com>
Subject Re: Poor transfer rate using HttpClient 4.3 on Windows 7/Server 2008
Date Thu, 22 May 2014 13:23:00 GMT
Hallo Oleg!

Thanks so far! I will contact Oracle about this issue.

Marco


2014-05-22 14:14 GMT+02:00 Oleg Kalnichevski <olegk@apache.org>:

> On Thu, 2014-05-22 at 11:23 +0200, Marco Wolff wrote:
> > Hallo Oleg,
> >
> > Yeah they seem to provide a default value for SO_RCVBUF and SO_SNDBUF
> from
> > the OS.
> > It seems like if they are not set, the OS returns a default value which
> is
> > way lower but which is not being autoscaled in regard of the possible
> size
> > the buffers could reach, allowing better nio performance.
> > I have checked that the autoscaling is enabled ('netsh int tcp show
> > global', value for 'autotuning' is 'normal') so the autoscaling should
> take
> > care of the sizes of the buffers.
> > Is it possible that we are experiencing a same issue like the following i
> > could find in regard of Apache MINA?
> > https://issues.apache.org/jira/browse/DIRMINA-561 There the problem was,
> > that the 'set*BufferSize()' was execute after that '.bind()' was already
> > called on the socket, which lead to the disabling of tcpip autoscaling.
> But
> > since you pointed out, that there is no meddling with the socket options,
> > what else could this be? A problem between the JVM native library and
> > Windows 7/Server 2008?
> >
> > Marco
> >
>
> At the moment HttpClient 4.3 does not provide config options for
> SO_RCVBUF and SO_SNDBUF parameters at all. I am going to add them in
> 4.4. This does seem to be a JRE issue as far as I can tell.
>
> Oleg
>
> >
> > 2014-05-21 13:51 GMT+02:00 Oleg Kalnichevski <olegk@apache.org>:
> >
> > > On Wed, 2014-05-21 at 09:30 +0200, Marco Wolff wrote:
> > > > I am developing a server and client software for data exchange,
> using the
> > > > HttpClient 4.3 in the client software (Java).
> > > >
> > > > I am experiencing a poor transfer rate when client is running on
> Windows
> > > > 7/Server 2008, meaning that the HttpClient is only using a small
> > > > percentage(20-40%) of the maximum bandwidth.
> > > >
> > > > Using the HttpClient on Mac OS X, Linux, Windows 8(.1) does result
> in a
> > > > transfer rate that uses the maximum bandwidth (+95%).
> > > >
> > > > I am able to fix this issue, setting the following registry entries
> in
> > > the
> > > > Windows registry on Windows 7/Server 2008:
> > > > Path:
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters
> > > > Creating two DWORD entries:
> > > > * DefaultReceiveWindow
> > > > * DefaultSendWindow
> > > > Setting them according to the actual bandwidth: (Up\Download in
> Kilobits
> > > *
> > > > 1024) / 8
> > > >
> > > > After reboot, client software using HttpClient 4.3 is using maximum
> > > > bandwidth (+95%).
> > > >
> > > > Could this be an issue with the buffer sizes of the sockets used in
> the
> > > > HttpClient 4.3?
> > > >
> > > > Is this a known issue in the context of the HttpClient 4.3
> > > implementation?
> > > > I found the mentioned fix after searching for a poor performance
> problem
> > > > with the Apache Server 2.2.X on Windows 7/ Server 2008. Does also
> occur
> > > in
> > > > HttpClient 3.2.
> > >
> > > Marco
> > >
> > > No, this is not an know issue. Are DefaultReceiveWindow and
> > > DefaultSendWindow the same as SO_SNDBUF and SO_RCVBUF socket
> parameters?
> > >
> > > By default HttpClient does not meddle with SO_SNDBUF and SO_RCVBUF
> > > parameters assuming they are set to an optimal value at the OS level.
> > >
> > > Oleg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message