- From: Jeff Pinner <jpinner@twitter.com>
- Date: Tue, 30 Sep 2014 15:55:00 -0700
- To: Greg Wilkins <gregw@intalio.com>
- Cc: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
> Then headers with static names and custom values don't need to be indexed. > For example after this change Jetty generates a date field only once per > second with a static date name index and a huffman encoded date value. > This precomputed field is then used 10's or 100s of thousands of times in > the next second. Previously we had to recalculate that field for each and > every connection because the date name index was different for every > connection. This isn't a compelling argument to me. Without indexing, you can still re-use the huffman encoded data value regardless of where the static table is. And if you do index, to say share this value between responses on the same HTTP/2 connection, then you have to lookup the offset even if the static table comes first. > > Similarly for the server header, we pre-compute and can send to every new > connection because we know what the server name index will be. Again here, you can none of the benefit of sharing the value amongst multiple responses on the same connection. You are trading off compression efficiency for not having to do a index lookup. > > Static content in the content cache can also pregenerate last-modified and > etag headers which again will get used on lots of different connections and > don't need to be regenerated. > > Previously we had pre-generated headers for http1, but were not able to add > the mechanism for h2 because every field was always custom generated for > each connection. After this change was made we were able to generalise > pre-generation for both h1 and h2 and this is a significant saving in > scalable servers. EVEN IF the cost was larger headers they would be > worthwhile, but the average header appears to be the same or a little > smaller. > So the TL;DR here seems to be you're not using indexing. My response is to use indexing, it has low computational overhead and you get much higher compression efficiency reusing these values.
Received on Tuesday, 30 September 2014 22:55:26 UTC