Vault's Ability to "Get" 100's of Individual Unique Files From Individual Unique File Paths

Vault's Ability to "Get" 100's of Individual Unique Files From Individual Unique File Paths

jacob.dillingham
Enthusiast Enthusiast
494 Views
2 Replies
Message 1 of 3

Vault's Ability to "Get" 100's of Individual Unique Files From Individual Unique File Paths

jacob.dillingham
Enthusiast
Enthusiast

Ok more of a theoretical problem. We have a vault server that has millions of unique Inventor part files. These part files are categorized and broken down into multiple layers of folders based on certain design characteristics of the part. This is our "Parts Library" that contains millions of part files, Terabytes worth. Say there's some assembly that has 500 of these unique part files, and each of the parts are located in a unique file path. When downloading/"Get" the assembly from Vault it may only be a couple Megabytes worth of total data. Regardless of how fast of a connection speed I have to the server itself would there be a significant slowdown in Vault's ability to navigate from one file path to the next in order to download the individual part file?

 

I know this is a weird question. We are having problems downloading from our server. If I download a singular large file that's like 300MB in size, I can download it at 100+Mbps. But once I start downloading these assemblies and the children parts, that can be similar in total size to the large file, but download speeds plummet to 10Mbps or even less.

 

And I think that slowdown is due to Vault "searching" the numerous file paths and file names for one specific file. I just don't know and can't test it. Wondering if anyone has any insight into this?

 

Also any insight into the background processes when a "get" is performed on an assembly file would be appreciated. Like for each part file does it go through a checklist is it checked out? is it checked out by you? do you have the most current version? is the file in a locked working state? then it downloads the data and moves to the next part with the same checklist?

0 Likes
495 Views
2 Replies
Replies (2)
Message 2 of 3

ihayesjr
Community Manager
Community Manager

@jacob.dillingham 

Vault knows exactly where the file is located, it is not "searching" through folders for the file.

Vault will compare the files in the local workspace to see whether it needs to download the file. 

Do you have any anti-virus software on your workstation that monitors the workspace?

You can also check the server log files to see if there are any issues on the server. 

 

Another test you could perform is to clear out your local folder. Download the same assembly and if there is a slow-down.




Irvin Hayes Jr
Principal Product Manager
Autodesk, Inc.

Vault - Under the Hood Blog
0 Likes
Message 3 of 3

jacob.dillingham
Enthusiast
Enthusiast

Yea I guess by searching I meant more of navigating to the file path and then comparing the vault file and local file. But I kinda realized that really can't be the problem because once I have all the files downloaded it doesn't take long for the comparing to finish when I get the same assembly again. Like I said I don't know every single behind the scenes process that Vault does when you get a file. But I imagine it's doing a lot more than just comparing existing files and possibly downloading the part files. but whenever I get one of these assemblies I can watch Task Manager for my network download and upload speeds and it'll just spike every second or so from 0Mbps Received to a couple hundred Kbps or Mbps and then immediately drop back down to 0. 

 

I deleted all the files from my local folder and it's a similar response. I don't have access to any of the server logs or anti virus software info. I work with about 60 other engineers that all experience these similar slowdowns whenever downloading these large assemblies. 

 

Since I don't have more in depth access to the server itself, I guess all I can get from the forum is if there's any background processes that Vault does on a Get that I don't know about?

0 Likes