- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Thu, 16 Aug 2012 16:26:00 -0400
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Robert Brewer <fumanchu@aminus.org>, Ilya Grigorik <ilya@igvita.com>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Patrick McManus <pmcmanus@mozilla.com>, ietf-http-wg@w3.org
Agreed, but that is not what I was proposing. What I was saying is that if people are going to throw up JSON Web Services as the reason for needing to compress HTTP headers they are overlooking the main source of bloat in their code. On Thu, Aug 16, 2012 at 4:13 PM, Roberto Peon <grmocg@gmail.com> wrote: > JSON is far more rich than we need. > name-value is really sufficient for anything the protocol should > contemplate. > I'm all for tokenization, btw, so long as the mapping for tokenization is > static for long periods of time (months/years) > -=R > > > On Thu, Aug 16, 2012 at 8:24 AM, Phillip Hallam-Baker <hallam@gmail.com> > wrote: >> >> 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/ >> > -- Website: http://hallambaker.com/
Received on Thursday, 16 August 2012 20:26:27 UTC