Re: FF Priority experiment

Martin,

well there are options to try to optimise the situation, but as you say I
was generally trying to illustrate the complexity.

So to consider your suggestion of separating active from passive streams,
that is something that we could consider.      However initially all we
will see is a priority frame and we will not know if that is going to be
for a passive or an active stream, so we'd have to create a passive
stream.  Then if it turns out to be an active stream, we will have to
convert it from passive to active, so if we have more active than passive
streams we may create more garbage and hit common stream maps more often
etc.

I also understand that the intent of the mechanism is targeted at when the
available resources exceed the pipe.   But if I've got 5 streams of a 20
request batch active and they are saturating the pipe, then the last thing
I want to do is launch the 15 other requests to be handled on the chance
that one of them might be higher priority than the 5 that have already
saturated the pipe.   I may do so if my server is idle and I've got nothing
else to do, but the chances are that those first 5 are all that the server
will consider, so if the top priority is in the next 15, then tough luck
for the client.

Building a scalable server is all about garbage collection, mechanical
sympathy, scheduling strategies, resource management, lock contention (or
lock free algorithms) and these are harder in http2 but the fewer
connections gives the potential for a better outcome, so I think it will be
worth it.   Adding browser resource priority to the long list of
consideration is just a long way down the list of server priorities.

If we just had simple low/normal/high absolute priorities on streams, then
they would be much easier to apply when a server has the situation of 5
active requests saturating the link.   Patricks proposal does help in this
regard as once we learn the FF-37 pattern we would be able to apply his 5
basic priorities to the currently active requests.    The problem is that
it is a per browser/connection pattern.

If the browsers are simplifying the problem to few priority buckets and the
servers can only really apply a few priority buckets, then it seams strange
for the clients buckets to talk to the servers buckets via a weighted
directed acyclic graph.

cheers





On 8 January 2015 at 18:02, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 8 January 2015 at 08:43, Greg Wilkins <gregw@intalio.com> wrote:
> > it can expect to have approximately 5 streams created to be held for the
> > entire life span of the connection, simply to define it's own absolute
> > priorities.
>
> Why not hold two structures?  Separating active streams and stream
> priorities seems fairly easy to do.  Active streams are strictly
> bounded, whereas stream priorities need garbage collection and all
> that mess.
>
> And I don't think that anyone is going to expect a server to hold
> responses.  The point of priority is to manage the case where all
> those responses don't fit into the pipe.  That said, part of the point
> of prioritization is to allow the server to take more responsibility
> for performance at the client end.  If you want to do that, then at
> least you have some information.
>
> (Point taken about the complexity, btw.)
>



-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.