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