Re: [tcpm] TCP Tuning for HTTP - update

On Wed, Aug 17, 2016 at 05:21:21PM -0700, Joe Touch wrote:
> Popping up to the key point...
> 
> On 8/17/2016 4:35 PM, Matthew Kerwin wrote:
> > Hi folks, I'm stepping in here on just a couple of points. I'll snip
> > the bits I can't or won't talk to.
> ...
> > Where we come from, how we find information to solve our problems, the
> > way we view the IETF and its RFCs are all different. If this argument
> > is just that this stuff doesn't belong in an RFC, that's a cultural
> > issue and not one I think we can resolve in this one technical working
> > group.
> 
> IMO, RFCs deal with *protocols* and protocol deployment issues.
> 
> Here that would mean for HTTP in specific
>     - turn Nagle off

All applications have been doing this for almost two decades.

>     - watch out for ACK compression effects (turn it off in favor of ABC
> if you can)

It does not happen that much with HTTP. Many connections on the server side
see only one, sometimes two requests, and most responses are small (about
20kB on average, with favicon fitting in a single segment). Note, I'm talking
about observations on average web sites.

>     - deal with slow-start restart (there are a variety of approaches here)

Due to the above this doesn't even happen most of the time, though with H/2
it will be more common.

> You also want to be generally efficient with TCP, which isn't related to
> HTTP but still good advice for all apps:
>     - be generally efficient and robust (use SACK, ECN, good window
> scaling, etc.)
>     - watch out for resource overloads (use SYN cookies/fast open,
> time-wait buildup, etc.)
> 
> That advice is useful for all TCP for transactions, too.

Absolutely, it's just that HTTP tends to magnify those effects because you
can get a lot of traffic concentrated on one or a few machines, and there's
a huge pressure on the admins as they know that there are tens of thousands
of visitors witnessing their performance issues. Performance is constantly
monitored by customers as well, trying to shrink the last millisecond to rank
better on search engines, which further adds to the pressure.

> Here's what it definitely does not mean:
>     - setting socket buffer sizes (that's an OS-ism, and may be useful
> for app designers to know, but isn''t directly part of TCP or HTTP)
>     - running an efficient server for small connections (that's a pure
> implementation performance issue, and depends on OS support for things
> like threads, process/thread pools, etc.)
>  
> I.e., OS-specific issues in running servers are not in scope IMO.

So what you have cited above are implementation details which are either
basic to any implementer or covered by the application itself. Admins
have already dealt with this in the default tuning and the application
has already done what is supposed to be done. Yet the admin is left with
a web site that is down under load, and they need to understand what
sysctls to change and what their effects can be on the short term (ie:
put the site back online) and the mid term (ie: limit the amount of
problems caused to random visitors). Lots of people for example enable
time-wait recycling because this is done by some people in benchmarks,
it's a single sysctl and they don't realize that they cause a lot of
issues even under moderate load.

> Keep in mind who reads RFCs - mostly protocol people. Managers take
> training courses to get certification, and that's where they learn their
> operational issues.

As Matthew said, admins tend to trust better the people who write the
protocols. Having an RFC authored by various protocol people will
definitely help make admins do the right thing.

Willy

Received on Thursday, 18 August 2016 05:40:10 UTC