It's no big deal, just a minor irritation. And I'm not sure if this is unique to my implementation hence I'm asking the question here.
Vault Pro 2015. For every item, and as shown below even on completely empty blank items, there's an inherent 3-4 second delay when loading the BOM tab. This is new behaviour and not present in previous releases although given the item restructuring done in 2015, it's easy to see why some things would be different. But this delay is quite inconvenient and can significantly and tangibly slow users down when navigating between items to view BOMs. On items that contain BOM data, there's an even greater delay now before the BOM is displayed.
Does anyone else see this on their setup? Does anyone have a reasonable explanation as to why we now have this default delay?
Solved! Go to Solution.
Solved by Neil_Cross. Go to Solution.
I have no idea how to reach out to a forum moderator, but can someone please either delete this entirely or if possible do something about this...
For the last 3 days, every hour, I'm getting an email saying Anonymous thinks my review was helpful... nobody has done that, and nobody is doing it five past the hour every hour. Can someone please sort this out as the emails are driving my nuts! This is a screen print of just today, this has been happening every hour for the last 3 days!
Bumping this.
Surely someone out there must use Items in Vault 2015... do you get this inherent delay? It happens even on brand new empty items.
I've just migrated a large system to 2015 which is going live tomorrow, the users are going to have my life over this delay.
This delay isn't there on VP2013, nor is it there on VP2016 as tested in beta. It's only 2015.
Since going live with 2015, this delay just jumped from ~4 secs on a test server to now ~10 secs on the live Vault server which has a ping time of <1ms.
This is shocking, this is a real REAL time waster and massively infuriating for all users using the Vault. This delay is not in 2013 or 2016, why 2015??
Hi Neil,
I assume you have probably tried typical solutions like defragmenting the database indexes? That aside, I'm not aware of any reasons why this would be slower in 2015 than in other releases. Probably your best bet would be to log a support case so as to get this issue investigated.
Paul
Hi Paul,
Yes the db was defragged and a recent sql maintenance task run against it at the weekend after migration. I'm 95% sure I restored this database into Vault 2016 and didn't experience these delays. However, I have just noticed I don't get these delays on a fresh empty new vault. So that's worrying.
I have another case open re db deadlocks that I'm waiting for some feedback on, some ERP exports are failing from vault due to these and it might be related. There's no lines logged in the vlog for these BOM call delays though.
I want to log a new case about this but I don't want to distract anyone from the original case re the deadlocks, as that's more important. Although this is really annoying and could point towards a larger issue.
Hi Neil,
just curious:
- how big is a large implementation - database size?
- everything on 1 server - sql + adms console?
if yes - is the machine big enough to resolve it?
Do you see memory bottlenecks, i/o bottlenecks on the hard disks?
I have a 44 GB item vault on a 2015R2 env. and I do not see this behaviour and have not seen it yet.
Thanks.
This is a ~35GB Item Vault, and it was a ~500GB filestore until the weekend when I ran a couple of purges against it now it's around ~400GB.
Yes everything is on 1 server, it used to be replicated across 5 sites but that was shut down a couple of years ago. There has historically been database problems with this Vault requiring direct fixes provided by devs, and we're currently experiencing dead locks when an Autodesk Consulting app is attempting to collect BOM info for an Item export. Mr Liska @ Autodesk Consulting discovered that.
The ADMS is on a very capable server, it has approx 64GB RAM and the SQL service is cycled daily when my incremental backup script kicks in at night. And as far as I know I don't see any hdd or RAM bottlenecks.
When I began this post I thought the delay was inherent to 2015 as I experienced this on 3 different ADMS servers using the same dataset. And over the xmas period I was working on the QA team for Vault 2016, I restored this dataset into 2016 and didn't experience these delays at all. That's why my mindset was geared towards pointing the finger at 2015... but then after creating a new empty Vault and not seeing any delay, I'm worried it's the Vault db itself now with issues.
Just want to conclude this thread in the event that someone else comes across it.
The delay is actually due to deadlock issues in the main Vault database. As it stands today, the several seconds delay on calling the BOM really is the least of my worries given the larger scale carnage caused by the deadlocks. Again, for anyone else possibly seeing this, this is mainly item export related when a call is made to collect BOM entities. This often results in excessive (hours) export times for Item BOMs and frequent failures resulting in Error 1313.
As this isn't product related, I'll wrap it up.
Hi
Also we have the same problems with Vault Pro 2015:
Several second delay to call the BOM
An impressive amount of deadlocks when editing the Item
Repeated failures resulting in error 1313 when exporting BOM
These problems were not present with Vault Pro 2011
We have sent the database to support Autodesk and we are awaiting a response:-)
Gianluca