- 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>
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 UTC