Microsoft Dynamics NAV Scalability: NAV 2009 Classic vs NAV 2013 RTC
Table locked by another user? Sluggish performance? These are just a couple of issues that often make customers think that they have outgrown their Microsoft Dynamics NAV system. After all, that’s the marketing message: Dynamics NAV is for small to medium sized businesses, so it obviously can’t support a large number of users or high transaction volume. I’m here to tell you that’s not always the case.
NAV 2009 Classic vs. NAV 2013 RTC
The Classic Client on the native database was lightning fast. But the reality is that the RoleTailored Client (RTC) with SQL Server is faster. Independent verifications (read, not Microsoft marketing material) proves this out.NAV 2013 RTC is roughly 30 percent faster than the NAV 2009 Classic Client on the Native Database and 500 percent faster than the NAV 2009 RTC.
For those of you who are still unfamiliar with the RTC, it is a server side solution. That means that all of the code executes on the server side. The Classic Client was a client side application, meaning that all of the data had to go back and forth between the client and the server every time a line of code needed it, slowing the application down. If you’ve ever tried to use the Classic Client from home, you know what I’m talking about.
There has also been increased caching efficiency with the NAV Service Tier. Previously, Dynamics NAV relied on SQL Server for all of the caching. With the introduction of the service tier in NAV 2009, each user was given the ability to maintain a separate, private cache for data that had been recently accessed. NAV 2013 introduced a global cache that is not only shared by users, but also is synchronized across NAV servers. There are essentially three cache levels to keep you from having to perform those costly disk reads.
NAV 2013 also introduced a processing queue for posting. Table locking isn’t going away and never will, but you can reduce the number of locks your users encounter. You do this essentially by only allowing a single, automated user to post. Since that user is the only user that can write to the tables, locks are impossible. When a user clicks “Post,” instead of actually posting, the system simply writes a record to a queue for that automated user to perform. ArcherPoint implemented a custom solution for this process for NAV 2009 for a customer that was posting 50,000+ transactions per day during peak season. They experienced zero table locks. Now, this functionality comes out of the box.
Microsoft is constantly making improvements in regards to performance. The deployment of NAV on Azure gives it the ability to handle hundreds of users on a single server. As it continues down this road, Microsoft will want to keep hardware costs for the data centers down, and the only way to do that is to continue to improve service tier performance.
The SQL Server team is also making improvements, although it isn’t clear how NAV will best utilize them yet. New versions will allow tables and indexes to live exclusively in memory. You’ll never have to read from disk for some things while using the system. Even with faster, solid-state disks, direct memory access is always going to be faster.
If you ask me, the future has never looked brighter for big companies and Dynamics NAV. It is one of the most scalable solutions on the market. Our businesses always grow, but it is next to impossible to grow out of NAV.
If you have further questions on the scalability of your Microsoft Dynamics NAV solution or are considering it for your company, please contact us at ArcherPoint. We’ll be happy to discuss your goals and requirements and help you determine the best path.
For more information on topics related to Microsoft Dynamics NAV development, read the ArcherPoint Developer Blog, written specifically for Dynamics NAV developers.