Re: SPDY Header Frames

when comparing against deflate you need to consider all the transactions
after the first one too. They compress much more effectively than the
first. (generally > 90% ratios). In a stream of ~80 requests, the first
one is only part of the story[*].

-P

[*] I didn't say it was an unimportant part :)

On Tue, 2012-07-17 at 07:36 -0700, James M Snell wrote:
> 
> 
> On Tue, Jul 17, 2012 at 6:48 AM, Phillip Hallam-Baker
> <hallam@gmail.com> wrote:
>         [snip]
>         There are design issues in SPDY that I find a little
>         troubling. I much
>         prefer using a compact encoding for headers over compression.
>         A
>         compact encoding is easier to implement and much easier to
>         debug. It
>         is also more robust as single bit errors are less likely to
>         lead to
>         catastrophe.
> 
> I definitely have to agree with preferring the compact encoding over
> compression. At the moment, I'm just not seeing the benefit of
> applying the compression.
> 
> 
> FWIW, I made a few additional tweaks to my test.. namely, reducing the
> header value size to max(int16), and eliminating the charset header
> with the assumption everything would be UTF-8 and the header block
> becomes a simple 116 bytes in length. The compressed size (done
> properly this time, albeit using the existing SPDY dictionary that
> obviously would need to be tweaked to account for the new structure)
> comes out to only 114 bytes... 
> 
> 
> Just for fun, I added in my chrome browser's user-agent string,
> swelling the encoded size to 237 bytes... compressed at 220. Again,
> Not enough of a savings to justify the additional cost.... and yeah,
> let's definitely see what we can do about fixing the whole user-agent
> crap-fest.
> 
> 
> - James

Received on Tuesday, 17 July 2012 16:23:46 UTC