- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Thu, 16 Aug 2012 11:24:53 -0400
- To: Robert Brewer <fumanchu@aminus.org>
- Cc: Ilya Grigorik <ilya@igvita.com>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Patrick McManus <pmcmanus@mozilla.com>, ietf-http-wg@w3.org
What really matters for performance is the number of packets rather than packet size. If you are worried about the packet size then you should not expect a general purpose transport to meet your needs. UDP is going to be better. Similarly, if you are using JSON then the JSON bloat is going to be a lot more overhead than HTTP bloat. I like tokenization as a strategy as the same approach can be used for both the JSON and the HTTP space saving. It also means that embedded devices can even use the tokenized form as a replacement for header and JSON syntax and only use one parser. I don't see much advantage to compression for small message sizes unless you can avoid transporting the compression dictionary which is exactly what tokenization does, only with a slight reduction in maximum efficiency and a huge reduction in complexity. On Thu, Aug 16, 2012 at 10:36 AM, Robert Brewer <fumanchu@aminus.org> wrote: > Ilya Grigorik wrote: >> > On Wed, Aug 15, 2012 at 4:36 AM, Henrik Frystyk Nielsen <henrikn@microsoft.com> wrote: >> > I completely agree that if you have very small entity bodies >> > then maturally the header size will matter getting more >> > requests into the pipe faster. However, in the tests that we >> > have done with actual data the size of the entity bodies was >> > large enough that the impact was minimal. This is especially >> > the case if you also do bundling/minification as it naturally >> > leads you to large entities. >> >> It's worth keeping in mind that we're seeing more and more web >> "applications", as opposed to pages. Frameworks like backbone, >> angular, etc, all frequently make very small (usually JSON >> encoded) requests to indicates record updates, or to pull >> specific objects on demand, from an HTTP endpoint.. All of that >> to say: many of these requests are just a few hundred bytes. >> Your typical CRUD operations are all great examples: a lotta >> headers for a tiny payload and a 204 response. The overhead >> there is huge, which is why we're seeing people starting to >> invent their own protocols. e.g. SwaggerRocket: >> http://blog.wordnik.com/introducing-swaggersocket-a-rest-over-websocket-protocol >> >> They shouldn't have to do this... > > They shouldn't have to invent their own protocols because there are already plenty of protocols optimized for small-grained messages. That doesn't mean HTTP, which is one of the few protocols which is optimized for large-grained messages (in order to trade efficiency for scalability), has to change to become one of them. > > > Robert Brewer > fumanchu@aminus.org -- Website: http://hallambaker.com/
Received on Thursday, 16 August 2012 15:25:21 UTC