Stefan Küng wrote:
> Please give it a test.
> If we don't find anything major, we'll release 1.3.0 very soon now.
Here's some first impressions.
Nothing wrong with TSVN here, just to let you know what an
unsuspecting user might run into.
* 1.2.6 is lightning fast against our local (LAN, http://, apache
2.0.54) subversion server.
* 1.3.0 RC1 took ca. 20 seconds to do simple operations like 'show log'.
* 1.3.0 RC2 takes 10 seconds to do a 'show log'.
Looking at network activity (http://, "show log"), things look like this:
0.0s client-> PROPFIND /trunk
4.5s <-server HTTP/401
4.6s client-> PROPFIND /trunk, SSP_NEGOTIATE
4.6s <-server SSP_CHALLENGE
4.6s client-> PROPFIND /trunk, SSP_AUTH
4.6s <-server HTTP/200 (XML data)
4.7s client-> PROPFIND /!svn, SSP_AUTH
4.7s <-server HTTP/401
4.7s client-> PROPFIND /!svn, SSP_NEGOTIATE
4.7s <-server SSP_CHALLENGE
4.7s client-> PROPFIND /!svn, SSP_AUTH
4.7s <-server HTTP/200 (XML data)
4.8s client-> PROPFIND /!svn/1108, SSP_AUTH
4.8s <-server HTTP/401
4.8s client-> PROPFIND /!svn/1108, SSP_NEGOTIATE
4.8s <-server SSP_CHALLENGE
4.8s client-> PROPFIND /!svn/1108, SSP_AUTH
4.8s <-server HTTP/200 (XML data)
Hereafter the entire above cycle repeats itself again, which could be
an indication that TSVN is requesting some information twice. Then
again, there could be subtle differences I haven't noticed.
Continuing...:
4.9s client-> Connection teardown
5.0s client-> Connect
5.0s client-> PROPFIND /trunk
9.5s <-server HTTP/401
9.6s client-> PROPFIND /trunk, SSP_NEGOTIATE
9.6s <-server SSP_CHALLENGE
9.6s client-> PROPFIND /trunk, SSP_AUTH
9.6s <-server HTTP/200 (XML data)
9.7s client-> PROPFIND /!svn, SSP_AUTH
9.7s <-server HTTP/401
9.7s client-> PROPFIND /!svn, SSP_NEGOTIATE
9.7s <-server SSP_CHALLENGE
9.7s client-> PROPFIND /!svn, SSP_AUTH
9.7s <-server HTTP/200 (XML data)
9.8s client-> REPORT /!svn/1108, SSP_AUTH
9.8s <-server HTTP/401
9.8s client-> REPORT /!svn/1108, SSP_NEGOTIATE
9.8s <-server SSP_CHALLENGE
9.8s client-> REPORT /!svn/1108, SSP_AUTH
9.8s <-server HTTP/200 (XML data)
9.8s <-server HTTP/200 (XML data)
9.8s <-server HTTP/200 (XML data)
9.8s <-server HTTP/200 (XML data)
9.8s <-server HTTP/200 (XML data)
9.8s client-> Connection teardown
So, what does the above tell?
Well.
* Obviously, I have a problem in my setup which causes a 5 second
delay every time a SSPI-able client opens a connection and tries to
fetch data. It has never shown it's ugly face before but it surfaces
now that I started to use TSVN 1.3.0.
If I find a solution to this problem, it might belong in the FAQ,
since other users upgrading to 1.3.0 might very well experience the
same problem :-/.
I'm not sure what the problem is, but there's a clue in the apache 2.0.54 log:
[error] (OS 87)The parameter is incorrect. : authentication failure
for "/trunk":
user unknown, reason: cannot generate context
Hrm.
* The Subversion server is discarding authentication tokens.
The client correctly tries to reuse an authentication token on the
open HTTP (keep-alive'd) connection, but the server refuses to accept
it. This causes a lot of superfluous network traffic :-/, as can be
seen in the network trace (look for 401's).
* The Subversion client sends it's XML request (PROPFIND, REPORT)
along with every single HTTP request, even ones that the client knows
for sure is never going to return any data. This is the
"SSP_NEGOTIATE" request, which is just a capability handshake thingy
which will always return "SSP_CHALLENGE". Seems like a waste too.
I'm aware that all of these items are Subversion specific, so no need
to point that out ;-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Jan 10 01:22:06 2006