It's probably just the logic in the ra_dav or ra_serf client network
module, enforcing proper webdav (and svn?) semantics. Every path
modified/deleted/added in a commit is a whole separate request. For
'adds', the client is likely doing an existence check: does the path
already exist? If so, fail the commit (the client is out of date).
Most of the time the answer is "404", i.e. "no, it doesn't exist, so
go ahead and PUT the file".) If this existence check didn't happen,
then there's a risk of the PUT simply overwriting an existing object.
Honestly, though: if you're worried about svn's performance over
HTTP, stop using HTTP. It's a lost battle. HTTP is stateless, slow,
and WebDAV is really complicated. We already rewrote it to use 30%
fewer requests earlier this year, and I doubt it can get much leaner.
If you want speed, you'll get an order-of-magnitude speedup by
switching to svn:// instead of http://.
On Thu, Oct 29, 2009 at 11:36 AM, <kmradke_at_rockwellcollins.com> wrote:
> In doing some performance tests, I noticed that each newly added file for a
> svn commit causes a separate HTTP request to the server which then returns
> a 404 error page. For large numbers of files over a high latency connection
> this is a significant amount of time. (Even worse if you have a large
> custom 404 page defined)
> Adding 1000 new files in a single commit over a connection with 500ms
> will waste over 8 minutes in this step alone.
> Is it by design that each newly added file in a commit requires the client
> to perform a separate HTTP request? (neon does two PROPFINDs
> per file, serf does one HEAD per file)
> Both client and server are v1.6.5. Client was the windows distribution
> from tigris. Server is self compiled on solaris 10 x86 using:
> APR_VER := 1.3.8
> APRUTIL_VER := 1.3.9
> NEON_VER := 0.28.6
> SERF_VER := 0.3.0
> Would the new working copy stuff change this behavior, or is it something
> required by webdav, or just never annoyed anyone enough to optimize it?
> I'm willing to look into it more, if the behavior isn't expected to change
> with the new working copy stuff...
> Kevin R.
Received on 2009-10-29 22:11:33 CET