Re: Retrieving Repository Structure Info

anthony:

see responses in-line.

jeff
sourcegear


Anthony Davis wrote:

> On our large repository, retrieving repository structure info is taking=
=20
> a very very long time.  The pattern is that first the server thinks=20
> about it for about 1.5 minutes, the data is nearly instantaneously=20
> transferred, then the client thinks about it for about 30 seconds (full=
=20
> processor load).  I have visions of the world=92s largest bubble sort=20
> happening when we get the files.=20

is this possibly after a vault server restart?  or perhaps on a client=20
that has not been connected to that repository in a couple of days?

if it is the prior, have you done any statistics / rebuilding of sql=20
server's indices in the last 8-12 months?


> We=92re buying a much better server for Vault to run on (should be very=
=20
> nice), and I promise that the gold support PO will be on its way soon J=
=20
> .  Hopefully the server (dual 3 GHz with 4 GB ram) will be sufficient. =
=20
> We have 25 users, so things do get busy.  The ol=92 P3 was having issue=
s.
>=20

assuming you haven't purchased anything yet, I would recommend something=20
with lightning fast disk i/o - even over dual cpus.  sql server is=20
plenty of i/o intensive, the faster things get to/from disk the better=20
your overall throughput will be.


> But my concern is really about the client side processing.  Is there=20
> something we can do to help this out?  Typically the answer is to get=20
> the overall node count of the repository down.  It would be really grea=
t=20
> if we could send things to other repositories. =20

i'll add hytec's name to this feature request.

Also, a way to convert
> old style snapshots into new labels would be very nice (we love the=20
> snapshots, but for many things, we were using them when a label would=20
> really be better.)=20
>=20

does hytec have way too many labels to create these by hand?  remember,=20
you can show a folder's history by version number, and then label the=20
folder from the history dialog.  once that has been completed, you can=20
safely delete the snapshot.

> So I guess, bottom line, I=92d like to have:
>=20
> A)      This operation a bit more optimized on both ends.
>=20
> B)      Way to move whole trees of data to other repositories.
>=20
> C)      Way to convert snapshots to labels
>=20
> D)      (I didn=92t talk about this) A way to recursively obliterate. =20
> Will it speed things up if data is obliterated?  I have problems=20
> obliterating things because it always says I have to obliterate=20
> something else, and that annoys me.=20
> =20
>=20
> Tony
> =20

i've logged customer requests for a, b, and c.

as for the obliterate.  you won't gain too much performance, since=20
deleted nodes are not in the current tree.  my recommendation would be=20
to let things be.

jeff