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

Re: HTTP/2 Expression of luke-warm interest: Varnish

From: Yoav Nir <ynir@checkpoint.com>
Date: Tue, 17 Jul 2012 10:21:49 +0300
To: Brian Pane <brianp@brianp.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <7FF50F01-73D8-4447-8F48-8E85C2E67078@checkpoint.com>

On Jul 17, 2012, at 9:25 AM, Brian Pane wrote:

> On Mon, Jul 16, 2012 at 2:18 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
>> In message <20120716204650.GI27010@1wt.eu>, Willy Tarreau writes:
>> 
>>> I also remember that in private with a few of us you proposed a draft
>>> that you never published. There were very valid concerns here. Why do
>>> you not share it so that good ideas can be picked from it ?
>> 
>> The main reason that it never made it to ID, is that there quite
>> clearly is no room in the timeplan for the kind of fundamental
>> contemplation I wanted to inspire, so it seemed a waste of both
>> my own and everybody elses time.
>> 
>> There's nothing secret about it, and I don't think there is anything
>> in it which havn't already been mentioned in emails too:
>> 
>>   http://phk.freebsd.dk/misc/draft-kamp-httpbis-http-20-architecture-01.txt
> 
> Thanks for sharing this.  Here are some thoughts on it, from my
> perspective as a person who develops load balancers for a living:
> 
> My key takeaway from your draft is that you're advocating for HTTP/2.0
> to have a wire format that can be parsed with efficiency much closer
> to TCP (fixed-sized fields, binary values, both the code and the data
> can fit in a small number of cache lines) than to HTTP/1.1
> (variable-length fields with nontrivial delimiter semantics, ASCII
> values, not-at-all-compact data, parsing code ends up being large and
> full of conditional branches).
> 
> On one hand, that concept has a definite appeal.  In ever web server,
> proxy, and load balancer on which I've ever worked, HTTP parsing has
> been embarrassingly expensive.  On the other hand, that embarrassingly
> expensive parsing cost still tends to be only a single-digit
> percentage of total CPU usage in real-world proxies.  

OK. The suspense is killing me. Where do the rest of the CPU cycles go. Reading PHK's draft, the router reads a request, parses it, and forwards it (almost as is) to another TCP stream. I can see how parsing takes some CPU cycles. Where does the rest go?

Thanks

Yoav
Received on Tuesday, 17 July 2012 07:22:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 July 2012 07:22:31 GMT