trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leif Hedstrom <zw...@apache.org>
Subject Re: Reverse proxy and large HTTP requests
Date Sat, 06 Sep 2014 00:12:01 GMT

On Sep 5, 2014, at 5:08 PM, Brian Geffon <briang@apache.org> wrote:

> You might try setting proxy.config.http.server_tcp_init_cwnd to something like 10.
> 

That doesn’t work on Linux (only on OmniOS afaik). If I recall, Linux upstream refused to
take the patches that would allow application support for this.


As of CentOS6.4 (I think?) the ICWND is default to 10. I don’t know what other distros do.
You can tweak this per route (or default) using the “ip route” command.

Also, one thing that has bitten me in the past is that “slow start restart”. After some
time (I *think* 2x RTT?) of idle, a TCP connection goes back to ICWND again. You can turn
this off, with a sysctl (net.ipv4.tcp_slow_start_after_idle).

Also, look at perhaps tuning your send / recv buffers. You might need to both adjust the kernel’s
settings, as well as the ATS configurations.


Cheers,
— Leif



> Brian
> 
> 
> On Fri, Sep 5, 2014 at 3:51 PM, Fabien Duranti <fduranti@ymail.com> wrote:
> Hello,
> 
> I am running a proof of concept with ATS 4.2.2 in reverse proxy mode to improve user
experience when accessing a web application over an high latency link ( 255ms RTT )
> 
> The setup is the following :
> 
> client -> ATS1 --- High latency link --- > ATS2 -> origin_server
> 
> all connections have SSL.
> 
> Everything behaves as expected when client requests are small, response times when connections
are established pretty much correspond to RTT + origin response time + the negligible ATS
processing time.
> However, when requests are bigger than something around 3000bytes (POSTs typically),
reponse times are  looking more like 2x RTT + origin response time.
> Running a network capture showed that when ATS1 sends a big request, there are on the
wire 2x 1500bytes packets sent, then wait for ATS2's ACK, then another small packet to send
the remaining of the request. That wait for the ACK pretty much makes response times mutltipled
by 2.
> I immediately thought about the TCP tunning of the operating system (RHEL6) could be
wrong but running the exact same request with curl on ATS1 wouldn't show that. on the wire
we would rather see two fragmented packets of 2650bytes + 800bytes and the response from ATS
2 comming shortly after the RTT.
> 
> Is there any misconfiguration in ATS that would explain this ? I tried  proxy.config.ssl.max_record_size
 = 0 then 1000, then 4000 but didn't see any difference
> 
> Thanks !
> 
> --
> Fabien Duranti
> 


Mime
View raw message