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

Re: Negotiating compression

From: Michael Sweet <msweet@apple.com>
Date: Thu, 29 May 2014 13:41:14 -0400
Cc: Willy Tarreau <w@1wt.eu>, David Krauss <potswa@gmail.com>, Jason Greene <jason.greene@redhat.com>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <224AD14A-87A8-42DB-8A81-7169399F87E2@apple.com>
To: Martin Thomson <martin.thomson@gmail.com>
Martin,

On May 29, 2014, at 12:12 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 29 May 2014 09:01, Willy Tarreau <w@1wt.eu> wrote:
>> Well, 1.6M instructions for a request is huge, whatever the processor size.
>> That would basically limit a 3 GHz CPU to 2000 requests/s when it can currently
>> 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.

Perhaps for the field names (which is a stretch but all of the standard headers can be encoded using the static header table indices so let's go with it), but any value that gets used (not just matched against a constant string) will need to be decoded.

For argument's sake, let's say that half of the request header bytes are from the names and delimiters, and then we only really need to use half of the values (we don't care about User-Agent, etc.) - that still leaves 400,000 instructions per header frame or approximately 2.5x10^14 instructions for 6B requests.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


Received on Thursday, 29 May 2014 17:41:47 UTC

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