Re: Straw Poll: Restore Header Table and Static Table Indices

[Greg Wilkins <[e-mail]>]

On 15 October 2014 04:17, Roberto Peon <[e-mail]> wrote:

> One byte more overhead is significant when the amount of overhead was
> typically one byte to begin with,
>

Well if looked at in that way, removing the reference set was an increase
of 0 bytes to 1 byte for many headers, so an infinite increase in size.
Yet when looked at overall, the impact was negligible.

I agree that we need good efficient compression for dynamic headers, and am
willing to consider changes to ensure we get the balance right (such as
reducing the static table).  But I think that switching the index's back
adjusts the balance too far away from the very common use case of static
headers and static header names.

Here are my numbers for the test data run with h2-14, then removing the
suggested static headers (except Date), then adding in the suggested static
values:

  *size* *H2-14* *reduced* *values*  0 63.50% 64.40% 62.10%  4096 34.50%
34.20% 33.50%  8192 33.20% 32.70% 32.60%  12288 33.30% 32.60% 32.50%
So for the test data, reducing the static table size has hardly any affect
and by adding in values, the effect is often slightly positive.    So such
a change looks to at least do no harm.     Question is, does it do any good
for lots of dynamic headers - I'm happy to try answer that, but can do so
only if somebody can give me some test data to run against.


The worst possible impact of this means that one cannot bit-blit a large
> number of static headers-- one must add them one at a time or fix them up.
>

Not just static headers, but dynamic headers that use static names.


> I'll bet that I can show that this makes almost zero difference in CPU
> when implemented properly (there is little magical about a bit-blit to
> begin with)-- I'd be shocked if we couldn't do 100s of millions of
> header-sets per second on a single core.
>

While I'm sure that dedicated code can be written to generate h2 headers
very quickly, the reality is that servers are not written to be dedicated
to h2.   The fast bulk of the header generation and handling code is
written protocol neutral and has to work for  http, spdy, h2, fastcgi,
etc.   In that environment we have found it extraordinary difficult to
introduce header pre-generation when the bytes generated are a function of
the connection and sequence that the header will be sent.   For example, we
regenerate headers when we move a static resource into the cache, which is
done without reference to any particular protocol or connection.      While
the actual operation of customising a header for a particular connection
might just be a lookup and an add, there is a lot of complexity required to
work out when and if this addition is needed and bringing all the required
information to the correct point in the code.

I know this is a specific example, but I am sure that in general far better
and simpler optimisations can be done with encodings that are immutable
rather than with ones that are a function of connection and time.

regards








-- 
Greg Wilkins <[e-mail]>  @  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.