On 07/24/2012 06:50 PM, Julian Foad wrote:
> Bert I just tried to add that a reparent is not a 'free' operation... It is
> still an expensive operation compared to many other operations... But
> compared to opening a new ra session it is still at least 10 times faster.
I was curious about just how expensive reparent was. I naively expected it
was a simple string operation (assuming the repos root URL was cached in the
session baton). For others who were wondering, here's what I found.
For ra_local: I was right. String math only.
For ra_serf: I was right again. It's just a string operation when the
repos root URL is known. But I overestimated how common it was for this
value to be known. All HTTPv2 servers transmit the repos root URL when the
session is initialized via the OPTIONS command. For older servers, the
repos root URL is calculated and cached opportunistically as part of other
operations, but isn't strictly guaranteed to have been determined before any
particular reparent operation occurs. And when discovered in this fashion,
it's done using the very sort of PROPFIND dance that HTTPv2 was introduced
to eliminate. So yeah, potentially pretty costly.
For ra_svn: I was totally wrong. This thing always requires network
activity: a "reparent" command/response at best; at worst, the complete
teardown and re-opening of the session. This is just a side-effect of the
stateful protocol. Unlike with HTTP, the server here is privy to the
"session URL" concept -- clients only perform operations using relpaths
against that URL -- and so the server must be told when that has changed.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-07-25 03:32:27 CEST