W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Negotiating compression

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 29 May 2014 10:37:00 -0700
Message-ID: <CAP+FsNfHg8DfSCRopVbMZgKaytyAwSqkGz-QoPadx0sJ6OPWTg@mail.gmail.com>
To: Jason Greene <jason.greene@redhat.com>
Cc: David Krauss <potswa@gmail.com>, Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>, Simone Bordet <simone.bordet@gmail.com>, Michael Sweet <msweet@apple.com>, Martin Thomson <martin.thomson@gmail.com>
...And this could be faster than the "bare" strings given it is a smaller
number of bytes.

In 2012, a not optimized delta encoder (which included Huffman encoding +
delta encoding) got the following results on a single core of my
workstation, which wasn't a particularly fast machine:

"Delta-coding took: 0.642199 seconds for: 104300 header frames or
6.15723e-06 per header or 162411 headers/sec or 8.88429e+07 bytes/sec"

Huffman decoding itself is *significantly* faster than this, when necessary
at all.


On May 29, 2014, at 11:12 AM, Martin Thomson <martin.thomson@gmail.com>

> On 29 May 2014 09:01, Willy Tarreau <w@1wt.eu> wrote:
>> Well, 1.6M instructions for a request is huge, whatever the processor
>> That would basically limit a 3 GHz CPU to 2000 requests/s when it can
>> do 300000 in http/1.1. I'm starting to be really worried...
> That assumes that you need to decode header fields.  There's no reason
> you can't do a byte-by-byte comparison in many cases.

That’s true. An optimal reverse proxy, for example, could do
method/location/path matching using bitmasks, and pass the message as a
direct copy.

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Thursday, 29 May 2014 17:37:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC