Re: [tcpm] TCP Tuning for HTTP - update
Willy Tarreau <w@1wt.eu> Thu, 18 August 2016 05:44 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FDB12D0BA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Aug 2016 22:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.168
X-Spam-Level:
X-Spam-Status: No, score=-8.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BhXHaCXpNeT for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Aug 2016 22:44:43 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE4B12B015 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Aug 2016 22:44:43 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1baG3w-0003KY-7u for ietf-http-wg-dist@listhub.w3.org; Thu, 18 Aug 2016 05:40:20 +0000
Resent-Date: Thu, 18 Aug 2016 05:40:20 +0000
Resent-Message-Id: <E1baG3w-0003KY-7u@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <w@1wt.eu>) id 1baG3m-0003JV-QH for ietf-http-wg@listhub.w3.org; Thu, 18 Aug 2016 05:40:10 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by maggie.w3.org with esmtp (Exim 4.80) (envelope-from <w@1wt.eu>) id 1baG3k-0008O0-S9 for ietf-http-wg@w3.org; Thu, 18 Aug 2016 05:40:10 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id u7I5cbuM017303; Thu, 18 Aug 2016 07:38:37 +0200
Date: Thu, 18 Aug 2016 07:38:37 +0200
From: Willy Tarreau <w@1wt.eu>
To: Joe Touch <touch@isi.edu>
Cc: Matthew Kerwin <matthew@kerwin.net.au>, Mark Nottingham <mnot@mnot.net>, tcpm@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <pmcmanus@mozilla.com>, Daniel Stenberg <daniel@haxx.se>
Message-ID: <20160818053837.GC16773@1wt.eu>
References: <5CD67877-19E3-4E79-BBF2-3E270343A378@mnot.net> <2197232f-10d7-28cb-fcc9-05bd495e3c22@isi.edu> <20160817064545.GD16017@1wt.eu> <7f7b129c-f156-d067-bef8-4a2213f461ac@isi.edu> <20160817180802.GA16773@1wt.eu> <4ab7c5b0-3722-1346-f481-a8d76de70034@isi.edu> <20160817211317.GA16929@1wt.eu> <c928d1ca-fc89-d0b0-4e1a-8a0bd960d2bb@isi.edu> <CACweHNC1qFH5DMnZRE87bAE5sk_P+1z1Fzm-9YEu=E2DULkaYQ@mail.gmail.com> <27b58b64-48cd-39af-78b3-ef583c585fa6@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <27b58b64-48cd-39af-78b3-ef583c585fa6@isi.edu>
User-Agent: Mutt/1.6.0 (2016-04-01)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.574, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1baG3k-0008O0-S9 5afa51f5c9b3dd31ab6d6e8c324cf5be
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <http://www.w3.org/mid/20160818053837.GC16773@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32307
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Eliot Lear
- Re: [tcpm] TCP Tuning for HTTP - update Willy Tarreau
- Re: [tcpm] TCP Tuning for HTTP - update Jeremy Harris
- Re: [tcpm] TCP Tuning for HTTP - update Mark Nottingham
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Willy Tarreau
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Willy Tarreau
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Willy Tarreau
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Mark Nottingham
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Mark Nottingham
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Matthew Kerwin
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Adrien de Croy
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Adrien de Croy
- Re: [tcpm] TCP Tuning for HTTP - update Willy Tarreau
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Willy Tarreau
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Tim Wicinski
- Re: [tcpm] TCP Tuning for HTTP - update Eliot Lear
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Alexey Melnikov
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Willy Tarreau
- Re: [tcpm] TCP Tuning for HTTP - update Mark Nottingham
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Mark Nottingham
- Re: [tcpm] TCP Tuning for HTTP - update Joe Touch
- Re: [tcpm] TCP Tuning for HTTP - update Jana Iyengar