W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 29 Feb 2012 20:09:20 +0100
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-ID: <20120229190920.GB3575@1wt.eu>
On Wed, Feb 29, 2012 at 01:46:54PM -0500, Patrick McManus wrote:
> On Wed, 2012-02-29 at 19:03 +0100, Willy Tarreau wrote:
> 
> > > To bring this back to compression - I just took a set of 100 compressed
> > > real headers, and passed them through a decompress/recompress filter
> > > 1000 times in 350 milliseconds on one core of a rather unimpressive i5.
> > > Spdy would do it faster because it tends to window things smaller than
> > > the default gzip. So that's a cpu overhead of .35ms per set of 100. The
> > > headers were reduced from 44KB (for the set of 100) to about ~4KB.
> > > That's probably a reduction from 31 packets to 3. IW=4 means that's a
> > > difference of 3 rtt's of delay to send 31 packets uncompressed vs 0
> > > delay to send 3 compressed. 
> > 
> > That's precisely what worries me a lot. You were able to compress "only"
> > 3000 requests per second on an i5, 
> 
> 3000 sets of 100 http transactions per second on 1 core of an i5 with a
> lame implementation. So that's 300,000 http transactions per second per
> core on a chip that costs ~$50 a core. not a big factor.

OK sorry I understood in the text above 1000 requests of 100 headers each
in 350 ms.

> I'll also note that it's not a moral failing if we specify a protocol
> that's good for the Internet that can be gatewayed to one that is better
> for back offices, although I don't think that has to happen. I think the
> work of the Internet protocol is the more important work of the IETF. 

It's not a moral failing, but for adoption you have to ensure that you
don't multiply server-side infrastructure costs by 100 too and you don't
expose them to new risks.

Regards,
Willy
Received on Wednesday, 29 February 2012 19:09:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT