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

[RUELLAN Herve <[e-mail]>]

I dug a bit into the numbers myself, to find which removed static headers had a strong influence on the compaction results.
For requests, there are two: ":scheme:http" and "accept-charset". ":scheme:http" is probably not a problem as more traffic is expected to move to https. "accept-charset" is apparently no more commonly used, but is still in the testing data.

For responses, there are also two: "date" and "via". Their impact is roughly the same, and significant only for 1K or 2K dynamic tables. Keeping or removing them depends on the tradeoff we want to make. For a generic web usage, keep them to gain a small compaction increase, for a more versatile usage, remove them to reduce the size of the static table.

Hervé.

> -----Original Message-----
> From: Greg Wilkins [mailto:[e-mail]]
> Sent: mercredi 15 octobre 2014 04:37
> To: Roberto Peon
> Cc: Willy Tarreau; Mark Nottingham; HTTP Working Group; Jeff Pinner
> Subject: Re: Straw Poll: Restore Header Table and Static Table Indices
> 
> 
> 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.