Greg Stein <gstein@lyra.org> writes:
> Heh. Nope. I'd like to know why the new system is so much slower. My initial
> thought was that it should be approximately the same speed. So what is
> throwing off the number by so much?
>
> I'd suggest a quick ethereal trace to see if there is something obviously
> stupid going on.
>
> Also note the separately-identified item: when we see add-file in an update
> report, let's do a Depth:1 PROPFIND to gather and hold all the properties.
> With that, we *should* be faster than the current checkout.
Well Greg, the ethereal trace shows us exactly what we expect.
In the old system, we do a PROPFIND of depth 1 everytime we hit a
directory; that automatically gets us all properties of all
children. So then we do a GET on each file, and poof, we're done. If
you look through the ethereal trace, you see nothing but GETs on
files, and depth-1 PROPFINDs on directories.
In the new system, ra_dav is parsing an outline describing the entire
tree to be added (names only.) Because every item is new ("added"),
we only do depth-0 PROPFINDs on directories, and *both* a PROPFIND and
GET on each file.
So all in all, the new system does many more network turnarounds, an
extra PROPFIND on every file. The number of network requests is
larger by approximately the number of files in the tree.
That would explain a 35% speed decrease, right?
Your suggestion makes sense. I think you mean, "when we see
add-*directory* in the report", ra_dav can do depth-1 propfind, all
the child props in memory, and thus avoid sending the extra PROPFIND
per file.
Should I proceed down that path? I don't think it will make the new
system faster than the old; it will probably make it the same speed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 20 20:06:46 2003