Get files via Vault Client is VERY SLOW

[Anonymous]

Hi there,

I have an issue downloading files from Vault Server. If I try to download a folder with 500 files (300MB) the download takes ages! I have a 1 Gbps network connection, the server is a Xeon with 60 GB RAM. We use Vault Professional 2017. The Vault Server is filled with about 2 Million files. Server load is not more then idle. I would say the problem is not the server.

What i have is, that the Vault client takes up tp 1,3 GB RAM an 100% load on one of the 12 cores! (Xeon CPU, 3,6 GHz)

I'm loading the folder without any dependents or parents or something else. It's just plain the files in that folder. I tried to select the all files (not the folder) all at once and get them, but there is no change.

Virus scanner and Windows defender are deactivated.

Any ideas?

regards Wolfgang

[michael.battcock]

Hey Wolfgang,

Have you checked this out yet? It's a pretty comprehensive guide on improving Vault performance, especially when talking about utilizing the "Get" command to pull down files locally.

How to improve Vault performance

[Anonymous]

Yes, I checked it, and I think there is nothing that helps with my problem. We upgraded our server only weeks ago with the help of our reseller. Not because of real problems but for he future needs.
I tried some other folders and resolved, that it isn't the size or the number of files that is the problem. I found some other folders, much bigger (3 GB), that are downloaded fast. And other ones, same size, that are slow. The fast ones even don't have the 100% load.
Most of the slow ones we put into the vault with vaultbcp several month ago. The issue came up, when I tried to migrate these and some of our older files. So I tried to repair the references, but without success. My last idea now is to migrate one of the smaller slow folders to solve the problem. But then: It will take ages to load and migrate them. So no good option. And the question is: Why should there be a connection between file version and loading speed in vault? And: What is the Vault Client doing all the time when it tries to load the files?
I tried it with TaskScheduler, (getthelastversion) but it is slow too.
So I have no good news but only more questions. But thanks anyway for all help!
Regards
Wolfgang

[pvillella-CAP]

Hi wschmid,

I realize this is a pretty old post but I came across it today while diagnosing a similar issue on our own Vault.

I figured out something really interesting that might give you and other users some insight into what is going on.

TLDR: Files in Vault that have been modified since the last ADMS indexing job may take significantly longer to GET than other files. The slowness is not specifically due to the number or size of the files you are GETting. It's all about the date it was modified.

As you mentioned, we have some folders with LOTS of files, totaling hundreds of megabytes, that we can Get very quickly -- no issues. However, other folders with fewer files and less files size may appear to lock up the Vault client and it takes many minutes to nearly an hour to Get the folder.

It was really puzzling and didn't make a lot of sense...until today I noticed this:

Files that have been modified today will often take much longer to Get.

As long as the files were modified prior to today, we can Get hundreds of them at a time with no performance issues. However, trying to Get even a few of the files that were recently modified results in a crazy delay.

Vault will eventually download them and the client doesn't every actually crash but you will get the 'Not Responding' message and it will sometimes freeze while it is doing the GET.

Why would this possibly be?

Why does Vault care if the file was modified today or not? I'm not sure of that yet but my hunch is that it is due to Indexing. Vault uses SQL Server, as we know. However, it also creates its own local index of that database (referred to as the Lucene index, I believe) and it is MUCH faster for Vault to look in its own index than to have to search in the SQL database index. Currently, we run the Search Index Optimization ADMS task only once per day, offloaded to non-production hours so that it doesn't impact work.  In my testing, it is clear that as long the Optimization job has run after the files in question have been modified, those files can be downloaded very quickly with the Get. If they have been modified today, i.e. before the Search Index Optimization job has completed, the Get will complete but it takes significantly longer to do so.

We have users who often need to Get files that have been modified recently by other users, so I'm considering adjusting the interval that I run the Optimization so that it re-indexes these files more quickly.  This should speed up the Get considerably.

If anyone else has experienced this behavior and has any other thoughts, I'd love to hear them.

I hope this observation helps someone else who has encountered this puzzling 'Slow Get' issue.

Cheers!

[TFoerst]

Hi @Anonymous,

is this slow download issue only on your PC?

[Anonymous]

Hi Patrick,

thank you for your detailed description. I checked this with our server, but, if I understand this correctly and files that aren't changed say longer than a month should come fast, it isn't the same here. I tested a folder that wasn't changed about 3 month, and it's very slow although it is just 500 MB and around 1700 files. It takes about 15 minutes to get it and most of the time it seems to do nothing.

regards

Wolfgang

[rtowne72]

From the networking side, is the hardware a SAN or a Standalone server?  Is the Switch you are plugged into dedicated to the Servers or for all the network?  Are you virtualized (ie VMware)?

We had an issue where it was slow on our end and some of it was FQDN and netbios was not being resolved correct at the DNS Servers.  Once IT looked into that our Speeds Improved greatly.

[Anonymous]

Hi Timon,

the problem is on all PCs.

regards

Wolfgang 

[prhoads3W8KL]

I am also having this issue, we uploaded to a new vault install last week, after verifying all data is present, tried a get of a large folder and it was very slow, less than 1Mbps at times, and we have a 1Gbps network.  Reading this post and some others, I tried many things to fix such as update to latest version (server, client, AND Inventor), reindexing, detatch/reattach vault, reboot server, etc, all to no avail. The only thing I have not tried is a full migrate, most of the files were migrated before upload, but there were still a number that were in 2013 version, and many were 2019.0, so I went ahead and downloaded the whole database to local workspace using “get”, after about 6 hours the get crashed.  I had a hard time actually figuring out if all of the files were downloaded or not, I had to do a “find” in the vault and add “Vault Status” column to sort and find all of the files that were not downloaded.  Finally after many failed attempts, I was able to confirm all files downloaded.  Then I started the migrate task in task scheduler to migrate the entire database to 2019.3.  I’ll report back if it helps.

[prhoads3W8KL]

So I performed the batch migrate, I made sure every inventor file in the vault was upgraded to 2019.3, and tried the download "get" again: this seems to have solved it.  Download on Friday was taking about 12 hours, now it is more like 12 minutes.  I feel bad for the groups who have a much bigger database than mine (mine is only 35k files, about 25GB), the migrate was painful, but for databases with millions of files, it would be next to impossible.  

[dg2405]

We've made a migration from ProductStream Professional to Vault 2 years ago. We have about 2 million files. The first time it was horrible to see the Vault-Performance compared with our older program. After investigating much time to understand why the performance is slow we noticed only one reason: It's the size of the local working folder. When the folder is empty, vault can be very fast. But after downloading only a few GB of files it takes from time to time longer to download. We've set up a synchronisation task to minimize the size of local workspace, now it's tolerable. Give it a try, delete all local files and see what happen with your download from vault.

Migration of files to a newer Inventor-Version is definitively a horrible thing with vault and should be overhauled.

[tony_berset]

Almost 2 years since the last message on this post but I encounter the same problem on Vault 2021. And I had the same observation : With an empty local workspace, getting files is fast. With a non-empty one, getting files could be very slow. I did the test on the same assembly (~700 files, ~1.7 Go), it goes from 2 minutes to 40 minutes to get the files!

Does Autodesk have an explanation about that ? Is there any solution except the workaround of frequently cleaning the local workspace ?

[ladislav.novak · Accepted solution]

I know it is kind of long dead thread, but no solution - i found solution for my quiet similiar problem. There was 20 000 .ipj.lnk shortcuts created by Inventor Apprentice in my \Documents\Inventor Apprentice for Vault folder. Every file downloaded from Vault was looking for the right one (last one) so it was number of files x 20 000 operations. I deleted those shortucts and it is sooo fast now.. Maybe it can help someone.