W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

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

From: Jason Greene <jason.greene@redhat.com>
Date: Wed, 25 Jun 2014 14:50:01 -0500
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <8AA4A63C-6298-4C4E-9191-08CA5ED9BE3B@redhat.com>
To: David Krauss <potswa@gmail.com>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC