trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fabien Duranti <fdura...@ymail.com>
Subject Re: Reverse proxy and large HTTP requests
Date Mon, 08 Sep 2014 21:52:00 GMT
Le 06/09/2014 02:12, Leif Hedstrom a écrit :
>
> On Sep 5, 2014, at 5:08 PM, Brian Geffon <briang@apache.org 
> <mailto: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
>
>
Thanks for the replies

It looks like changing ICWND on the route and turning off 
net.ipv4.tcp_slow_start_after_idle resolved the issue.

--
Fabien

>
>> Brian
>>
>>
>> On Fri, Sep 5, 2014 at 3:51 PM, Fabien Duranti <fduranti@ymail.com 
>> <mailto: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