Re: Stuck in a train -- reading HTTP/2 draft.

On Jun 24, 2014, at 2:08 AM, David Krauss <potswa@gmail.com> wrote:

> 
> On 2014–06–19, at 3:18 AM, Jason Greene <jason.greene@redhat.com> wrote:
> 
>> I share this opinion. The priority frames introduce way too much complexity for what is essentially a hint. Assuming it’s followed, it’s possible that the processing overhead of client directed scheduling might end up causing the very problem it’s intending to address.
> 
> Anyone attempting to implement it should know enough to use an algorithm of known O(1) computational complexity, although O(log N) choices are also viable.

The problem isn’t algorithmic complexity. Scheduling work using priority queues has more cpu contention and cost than a typical non fair scheduler. Further buffering/queuing to ensure priority means adding latency and consuming more server resources.

> 
>> Finally, since HTTP/2 is already over TCP, send order already offers clients a mechanism for assigning priority (although admittedly a bit basic).
> 
> This only works as long as the server processes requests serially, which isn’t even possible with a reverse proxy.

A reverse proxy doesn’t map well to the draft priority mechanism either because the client isn’t typically aware of which resources are proxied. 


> And it moves the scheduling complexity to the client side, which now must defer low-priority requests. Terrible architecture.

Yes, and this is a good thing. There is most likely more combined CPU resources from clients than there are in endpoints and intermediaries.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Wednesday, 25 June 2014 19:50:31 UTC