Re: Header Table and Static Table Indicies Switched

I have redone the numbers with the latest -09 hpack draft and the hpack
test data (4K header table)

38037 fields are compressed to 33.4%

  18647 49% Indexed custom field 1B
   7817 21% Literal  indexed static name 2B. Not indexed.
   4075 11% Literal indexed custom name 1B. Indexed.
   3938 10% Indexed static field 1B
   1313  3% Literal index custom name 2B. Not Indexed.
    720  2% Literal index static name 1B. Not Indexed.
    674  2% Literal. Indexed.
    384  1% Literal index static name 2B. Not Indexed.
    321  1% Indexed custom field 2B
    148  0% Literal index custom name 2B. Indexed.


Switching the indexes so static are high makes very little difference:

38037 files are compressed to 33.7%

  18968 50% Indexed custom field 1B
   8097 21% Literal indexed static name 2B. Not Indexed.
   3938 10% Indexed static field 1B
   3661 10% Literal Indexed static name 2B. Indexed.
   1029  3% Literal Indexed name 2B. Not Indexed.
    674  2% Literal. Indexed.
    440  1% Literal Indexed static name 1B. Not Indexed.
    414  1% Literal Indexed static name 1B. Indexed.
    384  1% Literal Indexed static name 2B. Not Indexed.
    284  1% Literal Indexed custom name 1B. Not Indexed.
    143  0% Literal Indexed custom name 1B. Indexed.
      5  0% Literal Indexed custom name 2B. Indexed.

So for the available data, static low index is marginally better overall
compression (but probably not significantly so as 0.3% better is well
within the variability of cases).

The differences between the tests in terms of number of 2B names vs 1B
names is also marginal. The -09 draft has 22% 2B static names and  3% 2B
custom names, while switching results in 32% static 2B names and 1% 2B
custom names.

So to reduce 2% of 2B custom names to 1B, we increase static 2B names by
10%!    Not a winning exchange for this data set.  Indeed that pretty much
accounts for the extra 3193B resulting from the switched indexed.

If static header names are more frequent than custom ones (as you would
expect them to be), then I think this result will be pretty much the same
on most data sets.


cheers









On 2 August 2014 13:25, Greg Wilkins <gregw@intalio.com> wrote:

>
> On 2 August 2014 12:30, Greg Wilkins <gregw@intalio.com> wrote:
>
>> that is just not correct.
>
>
> Sorry Jeff,  slight correction to my correction.
>
> For indexed fields there are 7 bits available.    These apply to custom
> fields whose values do not change every request (eg X-GData-Key:
> key=DEVELOPER_KEY), 65 entries are available in the header table that will
> encode to 1 byte fields.
>
> Literal fields with indexing have only 6 name bits available, so only 2 1
> bytes dynamic field name entries are available.   However, if the field
> value is changing every request, then an encoder should not be using the
> indexed encoding anyway, as the field will not be used again.   This
> encoding should only be used for fields that are expected not to change ie
> ones that do not need a name index encoding.   Perhaps this encoding can be
> used occasionally for a changing field to get a custom name into the header
> table for use with literal fields without indexing, but that is not a high
> frequency occurrence.
>
> Literal fields without indexing have only 4 name bits available, so
> regardless of the index ordering, many (most?) name indexes are going to be
> 2 bytes.    But at least the some common names of fields with changing
> values  (eg :path) will be 1 byte.  Note that an argument could be made to
> reorder the static table so other known fields with changing values (eg
> content-length and  if-modified-since) will have index's <16, but I'd like
> to see some data first to indicate that any such changes are significant.
>
> I stand by to run the numbers on any data set that anybody can make
> available to me.    I do have access to some live header streams, but
> nothing that would make any significant usage of custom headers.
>
> 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.
>



-- 
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.