Re: Experiences with HTTP/2 server push

[Tom Bergan <[e-mail]>]

Thanks all for the feedback.

On Fri, Aug 5, 2016 at 12:07 PM, Alcides Viamontes E <
[e-mail]> wrote:
>
> If browser and server are a bit far apart re-prioritization may arrive a
> bit too late to the server to be effective. Our solution for both  the race
> conditions and the RTT problem  is having our server learn the priorities
> and dependencies, build a delivery plan once and use it many times. In that
> sense, priorities and dependencies on the HTTP/2 spec as it is today is
> good enough for us. And the implementation complexity is about the same as
> implementing on-the-flight re-prioritization.
>

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?


> > 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?

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/

On Sun, Aug 7, 2016 at 7:02 PM, Martin Thomson <[e-mail]>
wrote:
>
> I think that you still misunderstand.  The priority tree is the
> client's data.  The server cannot mutate it because it doesn't own it.
> As you say, if the server makes changes, the state is ruined.


I'm not sure what I misunderstand? It sounds like we're saying the same
thing: the server should not mutate the priority tree if it wants to
continue using priority information from the client. (The counter-point is
Alcides' example, where the server uses its own delivery plan and ignores
the client's PRIORITY frames entirely.)

Note that no client I'm aware of will do anything with the server's
> PRIORITY frames, let alone adjust its own priority tree.
>

To be clear:

* As I mentioned above, I'm not aware of any server that tries to send
PRIORITY frames to the client. That discussion was intended to dissuade a
naive server from attempting to do so. AFAIK, servers that do mutate the
priority tree just mutate the server's in-memory representation of the
tree, e.g., I believe this is what Apache does with h2_session_set_prio,
which is applied to pushed streams (more info here
<https://httpd.apache.org/docs/trunk/mod/mod_http2.html#h2pushpriority>).

* Apache is technically not doing anything illegal. Servers are free to do
anything they want with priority information. (From Section 5.3: "priority
for a stream is input to a prioritization process. It does not guarantee
any particular processing or transmission order for the stream relative to
any other stream ... priority is therefore only a suggestion".) The problem
comes when servers want to mix their own priorities (e.g., for pushes) with
the client's priorities. It is tempting to do this by mutating a single
data structure. RFC 7540 doesn't discuss this temptation at all, which is
why we discussed it in our document.