Re: Experiences with HTTP/2 server push

Alcides Viamontes E <alcidesv@shimmercat.com> Mon, 08 August 2016 20:09 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 9CFE812B078 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 8 Aug 2016 13:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.167
X-Spam-Level:
X-Spam-Status: No, score=-8.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shimmercat-com.20150623.gappssmtp.com
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 R1h5pTdyd7hr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 8 Aug 2016 13:09:19 -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 AEC2212D150 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 8 Aug 2016 13:09:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bWqne-0000zr-0b for ietf-http-wg-dist@listhub.w3.org; Mon, 08 Aug 2016 20:05:26 +0000
Resent-Date: Mon, 08 Aug 2016 20:05:26 +0000
Resent-Message-Id: <E1bWqne-0000zr-0b@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <alcidesv@zunzun.se>) id 1bWqnX-0000yR-DY for ietf-http-wg@listhub.w3.org; Mon, 08 Aug 2016 20:05:19 +0000
Received: from mail-ua0-f172.google.com ([209.85.217.172]) by lisa.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <alcidesv@zunzun.se>) id 1bWqnH-0005N7-Jk for ietf-http-wg@w3.org; Mon, 08 Aug 2016 20:05:17 +0000
Received: by mail-ua0-f172.google.com with SMTP id 74so85534381uau.0 for <ietf-http-wg@w3.org>; Mon, 08 Aug 2016 13:04:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shimmercat-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=77nH7BYGAiMl+VIjKQKGHM2oxJ9dAiEdVO5GphWs2Z8=; b=a4FN2xkipk0FCkrN1tv/tDAxQtHadto1/U+yPlArJ057nfJJblbS39XoYya59nu5oJ OE7cwd7G3oTXQzuzS4ZC0cXgHLLcnLEy3k03RYZX65hOTVeqpBgborC84CPW9maL551W 8Kz1xbPRa2XI9Qy9hG58dUpWh9MD7eC+cAZCXVZ802y/mmh+o8wzMFkV3JiX12wY2j8c mIezbQ50Vo6yGbSTXkT2daI/mEccgb+J8dpURZ8bINtIQnBc16YQSYh13fmZe+Pg/jIB GtvEBoDew98w/qbVw6AmvBtdWCL3yWCbcIBIYyTpYB/r/AFXXngcKb9c6ZTBNfxaYkBN mpbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=77nH7BYGAiMl+VIjKQKGHM2oxJ9dAiEdVO5GphWs2Z8=; b=VjAmoAtAHvra4CKt2Ak0xbx7UqzkOd2bbMtdaXfyYaK+WKjgM/XAMeVbCDXrBEiU6v Agfq1jtfGznsVEdm9CwJs4tWhM4diawtr47WsApPv1LTyxop8iEyE+AqM+oPNsBvbozS cKFluijkNmHJJ4xRH9eSO0deP/7YeypM5eovmy8zsqJcyYnyZYTOFXwdxI+3wG+pCAkx vBDHYickl5XJk9dI1OwubATP+s31ZzjcRaCTz4CIzf2z3bDBuAWLWaCNQjQIJvd+xTg5 hKcGxxG9myIyFsXmmOKcNl43nZMcKbHheeGboMWQ3MY/78+uiMmfn4kmvTjrAGLfySnS 2xTQ==
X-Gm-Message-State: AEkooutxv/zhF9BlgQoNXIjVAgNGTq3KQyszOYNtlcJNOpGKdZGKVigMg0AAzgkuD45mEfjSlCT7aGlE1nHXLg==
X-Received: by 10.31.174.141 with SMTP id x135mr47862223vke.25.1470686676531; Mon, 08 Aug 2016 13:04:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.32.9 with HTTP; Mon, 8 Aug 2016 13:04:35 -0700 (PDT)
In-Reply-To: <CA+3+x5FY8ZQcM_HOWcfuFWuGTovohV=gW-tdJNiYyE0CJV1Npg@mail.gmail.com>
References: <CACZw55mUg_VjN3Q6TqPCb6udo3mQpoWQVNV5e2iYiNj=hC-2kw@mail.gmail.com> <CABkgnnX=6ZjnFJsh-07SDt+LMprsJ9w7tgSjaeaMKeEgihsD4g@mail.gmail.com> <CA+3+x5FpRGm9XQz2PdvFs6Kfiz3eMH1QLJ0fAeaeqQOSF2c9sw@mail.gmail.com> <CABkgnnWCm4gJ7fg3b8Ud=oBq5xYosoy3q=F3Tn_ChsXE4wHXaQ@mail.gmail.com> <CA+3+x5FY8ZQcM_HOWcfuFWuGTovohV=gW-tdJNiYyE0CJV1Npg@mail.gmail.com>
From: Alcides Viamontes E <alcidesv@shimmercat.com>
Date: Mon, 8 Aug 2016 22:04:35 +0200
Message-ID: <CAAMqGzY8XQorKs-00YiG3JFiZXApsFKwL2G5=5ZMJGKuafxJkg@mail.gmail.com>
To: Tom Bergan <tombergan@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Stefan Eissing <stefan.eissing@greenbytes.de>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=001a1144014eee6ae5053994ecfd
Received-SPF: pass client-ip=209.85.217.172; envelope-from=alcidesv@zunzun.se; helo=mail-ua0-f172.google.com
X-W3C-Hub-Spam-Status: No, score=-2.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: lisa.w3.org 1bWqnH-0005N7-Jk a7a29fd74137e45062ab6e4e909f6140
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Experiences with HTTP/2 server push
Archived-At: <http://www.w3.org/mid/CAAMqGzY8XQorKs-00YiG3JFiZXApsFKwL2G5=5ZMJGKuafxJkg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32229
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>

>
>
> If you can come up with a complete delivery plan on the server, that is
> definitely ideal. There is some academic work that tries to do this (see
> Klotski: https://www.usenix.org/node/189011). I also liked your
> "Coordinated Image Loading" article as an example of why server-defined
> priorities can be a good idea. I am curious though -- how do you deal with
> cases where the page is heavily dynamic and some of the important content
> may be fetched by XHRs? Do you expect that the full dependency information
> is available a priori, before the main response is served to the client?
>

Thanks for the link! I will take a closer look.

About dynamic content, so far we have focused on xhr content which is
fetched on initial page load. From version 1.0 up to 1.4 we have included a
learning mode that introduces small, artificial random pauses between DATA
frames of an HTTP/2 stream. We also make the  frames purposely small and
variable, say arond 512 bytes in length. Then we record the time when each
frame is delivered (as well as our server can know from the blanket of
abstractions that the OS provides). During initial page load multiple
streams are being downloaded in parallel, and the pauses help to improve
(up to a point, before the law of large numbers kicks in) overall
randomness in the process.  Therefore, on repeated loads of the same page,
frames from different streams which are almost always delivered very close
in time point out to some correlation between their streams. We sort the
correlations on the order of possible causality, and we postulate that
there is a dependency between the two streams. This works well even for xhr
content, where the browser doesn't provide explicit dependency information.

In simpler words, we use statistics to try to infer dependencies from the
browser's behavior. The only downside of our technique is that it uses too
much computing power to be able to run under 10 seconds on a developer's
laptop, because each page of the site which is significantly different to
the others needs to be fetched several times by a typical user agent, e.g.,
a browser. It would work great as a cloud service though. And it is also
good enough to run as part of CI workflows.



>
>
>> > Our team has been experimenting with H2 server push at Google for a few
>>>> > months. We found that it takes a surprising amount of careful
>>>> reasoning to
>>>> > understand why your web page is or isn't seeing better performance
>>>> with H2
>>>> > push.
>>>
>>>
>> Oh, but it is a lot of fun :-)
>>
>
> It is for us too :-), but I imagine many devs would find it frustrating.
> Hence our attempt to try to distill our experiences into a "best practices"
> doc.
>
>
>> In our experience as well the biggest performance killer of HTTP/2 Push
>> is TCP slow start and the fact that push promises are bulky. Send many of
>> them and an ACK round-trip will be needed.
>>
>
> Interesting point about needing ACK round-trips just to send the push
> promises. We hadn't run across that problem specifically. Is this because
> you're sending many push promises? Is there some reason why hpack cannot
> compress a sequence of push promises?
>
>
Yes, in our early prototypes we just wanted to see how far the technique
would take us, so we grabbed a bloated HTML template and tried to push all
of it in the order our algorithms were spitting out ;-) .


> If you've released any data about HTTP/2 Push performance in ShimmerCat,
> I'd be interested to read it. I did notice one article on your site,
> although that only dealt with one page with a fixed network connection:
> https://www.shimmercat.com/en/info/articles/performance/
>
>
What would you consider an interesting, standard measure for this case? We
are mainly interested on reducing the impact of latency on page load time.
So we tend to measure how the page load time decreases  for a client  with
latency around 120 ms. That's easy to standardize, but the other variable
is the website itself and that one is harder to standardize. In our
consultancy projects we tend to set a 30 to 50% improvement in load time
and time-to-start-reading over baseline as an achievable target goal, but
each project is quite unique :-( .