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

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

> On Mon, Jul 16, 2012 at 2:18 PM, Poul-Henning Kamp <> wrote:
>> In message <>, 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:
> 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?



Received on Tuesday, 17 July 2012 07:22:23 UTC