On Mon, 2008-02-25 at 11:04 +0100, Erik Huelsmann wrote:
> On 2/25/08, Chris Rose <chris.rose_at_messagingdirect.com> wrote:
> > I suppose this is true, but the wide range of client environments in which
> > I've seen this suggests something else. Probably network. And, I assume,
> > svn only sends one copy over the wire :)
>
> I'm sorry, but you have 5 people telling you it's *not* the network
> and server, it's the working copy. I'm one of the people writing the
> working copy code and I'm telling you it's the working copy. Now you
> can keep telling us its not true, but as far as I understand *you* are
> the new user here.
>
> > It might be a latency issue in the network; we've got a few other issues
> > like that. Given the higher count of roundtrips that would make sense.
>
> That would make sense, especially if you use the HTTP protocol with
> the Neon library. You could try building the soon-to-be-released
> 1.5-alpha1 version with Serf library. That could tell you the impact
> of the higher number of connections: Serf uses the HTTP/1.1 protocol
> with request-pipelining in order to reduce the number of connections
> used.
>
> But, even though it will be faster, I expect the factor 2 to stay
> roughly the same: the working copy library still has to do twice the
> I/O CVS does.
>
>
> HTH,
>
>
> Erik.
>
For us, the real bottleneck is (as always) the path based authentication
done with the apache server. The server feels the need to authenticate
each and every file access request, and if your authorisation method is
not well tuned, it is VERY painful. We started with mod_auth_krb to
authenticate against an ADS server, and found that each file fetched on
a checkout required:
1) Fetch request
2) Name resolution for ADS server
3) Name resolution for Kerberos admin ( I think)
3) Several messages for Kerberos authentication (I forget how many, but
perhaps 4)
4) Finally, the file was delivered.
To check out (for example) our local copy of the ECos source tree would
take some time.
We tweaked the kerberos config files to use IP addresses instead of
names, and things improved.
The short answer is that still find the path based authentication on the
apache server to be the limiting factor.
We run svn+ssh access on the same machine, and it is about twice as fast
to the same client.
We desperately wish that the server side credentials could be cached for
a checkout (or update, or log, or whatever), as I am pretty sure that
would provide a big speedup.
Don't get me wrong, we love subversion, even if it is slower, and think
the developers are doing a great job. If you can speed up the http +
AuthZSVN stuff, that would be a big improvement for us.
Thanks,
Tony Butt
Senior Software Engineer
CEA Technologies
Canberra, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-26 01:02:56 CET