If you have to start a new relational database transaction for each http post when submitting hundreds of posts, that's going to create a lot of overhead, if you choose to use session ids and leave the tranaction open, then you risk not committing something. If you use database pools, you are protected both ways I believe.
Still, that's a lot of open connections. On Feb 15, 2013 2:58 AM, "J. Andrew Rogers" <and...@jarbox.org> wrote: > > On Feb 15, 2013, at 12:10 AM, John Carlson <yottz...@gmail.com> wrote: > > > > I can't say anything about REST in general being slow. I would like to > see better support for adding multiple objects to a collection in HTTP > REST, perhap by using MIME. > > > REST is not a highly efficient protocol by any means but most of the > slowness people attribute to REST has more to do with what people transport > inside a REST operation than REST itself. REST is often below the > performance noise floor if it is well-used despite its inefficiencies. > > REST is commonly used to transport XML or JSON or similar. Parsing JSON or > XML encoding structures is quite slow because they are intrinsically > inefficient as wire encoding formats. Compared to common efficient > encodings, the difference in cost exceeds an order of magnitude in > practice. For example, I currently have a system that parses, processes, > and indexes complex geodetic polygons at sustained rates of many gigabytes > per second (for real-time petabyte-scale sensing models of the Earth). The > largest total consumer of CPU time by far is not computational geometry, > network processing, or anything like that but parsing JSON source formats > -- and we've invested a lot of time in highly optimizing JSON parsing. The > internal binary format used by the same system disappears below the noise > floor. > > As a practical matter, most people that use REST use JSON or XML and most > people that don't use JSON and XML also don't use REST for related reasons. > But it is not fair to blame REST for what is primarily an issue with JSON > and XML even though they are often seen together. REST is not efficient but > it usually pretty low on the long list of things that are slowing down an > application. > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
