- From: Roy T. Fielding <fielding@apache.org>
- Date: Thu, 12 Sep 2002 16:01:23 +0200
- To: "Babich, Alan" <ABabich@filenet.com>
- Cc: w3c-dist-auth@w3.org
>>> In the spirit of that analogy, I >>> am proposing that the entire transaction, conditional processing and >>> all, >>> should be invoked by one method call. That would do a lot to help >>> protect >>> the performance of the system. > > It would do nothing to help protect the performance of the system. > There is no effective difference between a sequence of requests with > time-outs per request and a batch request with time-outs per read. > The server still has to accumulate requests in storage and is > subject to the same service problems with stateful behavior. > > ...snip... > > ....Roy > > That's completely false. I suggest you learn how to write an HTTP server before making statements like that. > Last first. The only way to eliminate state on the server that must be > maintained between method calls ("stateful behavior") is to do the entire > transaction during one method call. Period. That's specious. The only difference between one method containing many requests and one connection containing many methods is syntax and the number of server responses on that connection. In one case you are building state because of HTTP methods and the other because of XML methods. The server responses are not in the critical path and therefore do not impact performance other than giving the client important information that might be useful to determining whether it should abort the transaction. > Going over the network multiple times for multiple method calls clearly > consumes more computing resources and elapsed time than making a single > method call. There is more overhead on the client (which doesn't matter) > and > the server (which matters a lot). That's really obvious. Pipelined requests make the difference irrelevant. The overhead of parsing XML far exceeds the overhead imposed by parsing multiple HTTP requests. And, yes, non-idempotent methods can be pipelined if they are sent as part of the context of a transaction, since building a transaction context is inherently safe. > But where client application programmers can really kill the performance > of > the entire system is by introducing the possibility of user think time > into > the middle of a transaction. That is only possible when the transaction > can > consist of multiple method calls. Unless you have time-outs on the transaction, which is true of any performance limited system. The protocol represents a wire syntax. If you think that merely packaging multiple requests into a single request method will force clients to send all requests at once, then you seriously underestimate the creativity of HTTP client developers. At least with multiple methods the server has a chance to respond appropriately in the middle of the stream of requests, rather than having to special-case the in-body request timeout handler. > Between the method calls, the resources changed have to be locked on the > server. That's not how I described transactions. I said that the requests are collected on the server and only applied when the commit message is received. If the state has changed such that the methods are no longer applicable, then the method transaction will fail on commit. ....Roy
Received on Thursday, 12 September 2002 10:03:00 UTC