Re: [tcpm] TCP Tuning for HTTP - update

[Willy Tarreau <[e-mail]>]

On Wed, Aug 17, 2016 at 08:14:08AM -0700, Joe Touch wrote:
> There are many other sites - and books - that already indicate how to
> configure systems efficiently.
> 
> So if your argument is that a man page summary is needed, sure - but
> again, is a new one needed? And why is this then needed as an RFC?

The difference is that a man page is OS-specific while an RFC gets a
unique number and serves as a reference. It can be cited in new RFCs
to justify certain choices. It can receive errata. You would probably
say that the current document is very linux-centric for now but I
understood it as a beginning of something more generic where advices
are given based on principles before sysctls and that the resulting
sysctls are just examples of applications of the principles in the
document.

> > Also, I don't know if there have been any update, but these documents use
> > SunOS 4.1.3 running on a sparc 20 as a reference. While I used to love
> > working on such systems 20 years ago, they predate the web era and systems
> > have evolved a lot since to deal with high traffic. ...
> Yes, and discussing those issues would be useful - but not in this
> document either.

Why ? Lots of admins don't understand why the time_wait timeout remains
at 240 seconds on Solaris with people saying "if you want to be conservative
don't touch it but if you want to be modern simply shrink it to 30 seconds
or so". People need to understand why advices have changed over 3 decades.

> > So you need to expect that only researchers and maybe TCP stack developers
> > will find your work useful these days, server admins can hardly use this
> > anymore. However it is very possible that some TCP stacks have taken benefit
> > of your work to reach the level of performance they achieve right now, I
> > don't know. Thus I think that Daniel's work completes quite well what you've
> > done in that it directly addresses people's concerns without requiring the
> > scientific background.
> Let me see if I get your complete argument:
> 
>     - the appropriate refs are 20 years old
>     - server admins need a doc
> 
> What exactly do server admins need regarding Nagle (which is configured
> inside the app already), socket sizing (configured inside the app), etc?

Lots of things : 
  - time_wait tuning (which everybody gives different advices on, I've
    even seen firewall vendors recommend to shrink it to one second because
    it allowed their product to perform better in benchmarks)

  - TCP timestamps: what they provide, what are the risks (some people in
    banking environments refuse to enable them so that they cannot be used
    as an oracle to help in timing attacks).

  - window scaling : how much is needed.

  - socket sizing : contrary to what you write, there's a lot of tuning
    on the web where people set the default buffer sizes to 16MB without
    understanding the impacts when dealing with many sockets

  - SACK : why it's better. DSACK what it adds on top of SACK.

  - ECN : is it needed ? does it really work ? where does it cause issues ?

  - SYN cookies : benefits, risks

  - TCP reuse/recycling : benefits, risks

  - dealing with buffer bloat : tradeoffs between NIC-based acceleration
    and pacing

  - what are orphans and why you should care about them in HTTP close mode

  - TCP fastopen : how does it work, what type of workload is improved,
    what are the risks (ie: do not enable socket creation without cookie
    by default just because you find it reduces your server load)

  - whether to choose a short or a large SYN backlog depending on your
    workload (ie: do you prefer to process everything even if the dequeuing
    is expensive or to drop early in order to recover fast).

... and probably many other that don't immediately come to my mind. None
of these ones was a real issue 20 years ago. All of them became issues for
many web server admins who just copy-paste random settings from various
blogs found on the net who just copy the same stupidities over and over
resulting in the same trouble being caused to each of their reader.

> I.e., at the most this is a man page (specific to an OS). At the least,
> this isn't useful at all.

As you can see above, nothing I cited was OS-specific but only workload
specific. That's why I think that an informational RFC is much more suited
to this than an OS-specific man page. The OS man page may rely on the RFC
to propose various tuning profiles for different workloads however.

Regards,
Willy