Skip to content

Greg Kaupp's picture

Performance Tuning Microsoft Dynamics NAV 2009 RTC and NAV 2013

ArcherPoint How-To Blog: Step-by-step instructions on how to perform specific tasks in Microsoft Dynamics NAV

We recently discovered that a single property on the Service Tier for Microsoft Dynamics NAV 2009 RTC and Microsoft Dynamics NAV 2013 has a bigger impact on performance than almost anything else we have done to date in performance tuning Microsoft Dynamics NAV in a 3-Tier environment. The setting that every client and partner should review is the MetadataProviderCacheSize for each Service Tier or Navision Application Server (NAS), which is set to 150 by default. What this means is that the NAS only caches 150 objects of the roughly 4,000 objects plus in a Microsoft Dynamics NAV database. The default setting is not much of an issue if the users who are accessing a particular NAS are all doing the same thing, which does not require caching more than 150 objects. However as soon as multiple departments or functions are accessing the same NAS then the NAS needs to continuously retrieve the objects from the database, which causes a significant degradation in performance.

Our recommendation is to set the MetadataProviderCacheSize to 5,000, which is more objects than exist in a typical Microsoft Dynamics NAV database and ensures that short of restarting a NAS that all objects are retrieved only once. We have seen significant performance improvements in our clients’ environments where they were experiencing performance issues by doing nothing more than increasing this property. I would encourage everyone to increase this setting whether or not you are experiencing performance issues since there is almost no reason not to and the benefits are tremendous the more people are accessing a particular NAS running different types of processes.

If you enjoyed this blog, you might like to check out our collection of Development Blogs, as well as our "How To" blogs for practical advice on using Microsoft Dynamics NAV.

Comments

Comment: 

This one change did wonders for our performance, our AP and AR staff have noticed a remarkable improvement since implementing this. Previously I would get complaints several time weekly from various user. Given the high volume of manually keying they do with sales invoices and purchase orders, this has been a true productivity boon.

Greg Kaupp's picture

Comment: 

I'm so glad that this helped.  It is truly amazing what that one little setting does for performance.

Comment: 

Are there any tools for (or automation scripts in) Dynamics NAV 2009 we can run to compare performance before/after changing MetadataProviderCacheSize from 150 to 5000?

Your article mentioned "roughly 4,000 objects plus". Is there a way to see how many objects we have? If it turns out we have 4218 objects, I assume setting MetadataProviderCacheSize to 4218 would be better than setting it to 5000, but maybe not. On the other hand, if we actually have 4218 and set it to 12000, I'm sure performance would not be any better than had we set it to 5000 -- but what is actually happening on the server? Does it allocate (waste) an additional 7000 KB of RAM or?

On another note, our Dynamics server sees a spike in IOPS (~1200) every hour for 24 hours, Mon-Fri, and we are trying to locate the source. We looked at every job in our SQL Server but the only hourly ones we see are scheduled on the half (7:30, 8:30, etc.) while the IOPS spike is happening on the hour (7:00, 8:00, etc.) What is the best way to locate the source of the IOPS spike?

Comment: 

I found the source of our IOPS spike -- the transaction log backup. Our SQL Admin told me it was running on the half (7:30, 8:30, etc.) but I double-checked and found it was set on the hour (7:00, 8:00, etc.)
We are moving towards a virtualized environment. The DPACK (Dell Performance Analysis Collection Kit) results showed all 7 of our servers generate ~2400 IOPS at  99% -- so when half of those IOPS came from just 1 server, that server became our focus.
My initial thought is to replace the hourly ~1200 IOPS spike (transaction log backups) with a continuous, but much lower, IOPS need (transactional replication). This would allow us to purchase a far less expensive SAN solution but I'm not sure if transactional replication has any disadvantages compared to doing hourly transaction log backups.

Comment: 

NAV 2013 has around 4000 objects. NAV 2009R2 has around 6000. It's doubtful that all objects would ever be used. However, memory is relatively cheap, so, it's not worth it to worry about what the exact value of the MetadataProviderCacheSize should be. 5000 will ensure optimum cache for everyone and is what ArcherPoint is recommending.

Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube
Get Help Now