Re: Large Frame Proposal

On 9 July 2014 13:42, Roberto Peon <grmocg@gmail.com> wrote:

> Allowing a large frame-size setting for any stream implies a loss of
> reactivity for all other streams within that connection, so long as the
> stream with the larger framesize is used.
>
> Essentially, it adds HOL blocking in. A frame size of 2^32, would
> potentially imply seconds of latency, and a failure of the protocol to
> deliver adequately.
>

Indeed, that is why the proposal includes setting limits that should only
be increased when it is known that QoS will not be affected or is not
important.   Nobody is saying that sending 2^31-1 frames will not hurt QoS.



> Larger framesizes matter only for non-TLS connections.
>

And TLS is very frequently offloaded and will be more often if the browsers
insist on making it mandatory.

So large framesizes may only be applicable for traffic within the data
centre, but any such workload I can get off my server the better!

Even for dynamic generated content from JSPs, Servlets etc. we have found
that it is far more scalable to give them a nice big 64KB or 128KB buffer
so they can run to completion without blocking and we can then flush that
buffer asynchronously.

It is also not yet given if TLS only deployment of h2 will be widely
accepted.

regards







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