BLOG

NAV Three-Tier Performance and Load Balancing

Disclaimer: This article is not meant to be a best-practice guide! It’s my first publication on LinkedIn, in which I’ve tried to summarize and share some of the information I found scattered through the interwebs. Also, I hope to gain tips & tricks from you. I still don’t have a solid answer on questions found below (although, admittedly, I haven’t directly consulted Microsoft). More advice is always welcome!

In 2008, Microsoft shocked the Navision world by introducing Dynamics NAV 2009. It gave us a new three-tier architecture that has brought a lot of advantages. I started using NAV 2009R2 Classic in 2012 and was a bit skeptical about all that “newness”, but after working with it for a year (mainly 2013, 2013R2 and 2015), I can wholeheartedly say it’s a huge improvement.

Even though it’s a really matured environment, I’m having difficulties finding knowledge on the topic, especially concerning the RTC-client and it’s service-tiers. For example, after consulting a few Microsoft partners, consultants, developers and asking them if the middle tier load balances by itself or if I should set up a certain number of middle tiers, I didn’t find the clear, well-documented answers I am used to in the NAV community.

What I’d like to tune, and why

The few large Dynamics NAV three-tier environments I’ve seen had a few things in common:

  •  Defining “large”, 100+ concurrent users in one database, and all or most users working in one company;
  • Database server and service-tier(s) on dedicated servers;
  • A fairly well performing database server (fast direct SQL-queries);
  • Low CPU usage and low memory usage on the service-tiers; Two to three servicetiers for over 100 users.
  •  Mediocre to fair performance in the client.

Of course, people can live and work with fair performance, but I’d prefer the user to be the limiting factor! Therefore I started looking into how to performance-tweak two of these environments.

What screws do I turn to make it go faster?

Even though I asked quite a few people, I found only a few things to look at:

  • SQL Server: Like in older versions of Dynamics NAV, the database can make or break performance in an environment. When switching from Classic clients to RTC, if you were happy with performance before the migration, it wouldn’t be the first place I’d look for gaining performance: In a three-tier environment the middle-tier acts as a buffer between clients and the database. Because of this, load on the database is less than when directly connecting clients to the DB.
  •  Page Design: If your NAV environment is customized, it is worth the hassle to invest time in your page design. I won’t go into detail here, but lots of fields in list pages, FactBoxes and pages with subpages accessing multiple tables will slow clients down. Of course, users can switch FactBoxes off by themselves to speed the system up… but they can also switch them ón to slow it down, if they need the information!
  • Network Protocol: This shouldn’t affect performance on fast LAN networks, but when connecting through a slow network or VPN fixing the Network Protocol on Sockets should improve performance. However, this is the protocol used by the service-tier to communicate with the database. I didn’t notice any improvement in my test environment.
  • Metadata Provider Cache Size: In Classic environments, one would set the Object Cache (KB) as high as possible to improve client performance. This is a similar setting, but now NAV objects are being cached in the service tier. The default setting is 150 (objects), and I really don’t know why it is this low – a dedicated middle-tier server should have at least 16GB of RAM, why not use it? Because I didn’t configure different service tiers for different departments (so basically everybody uses all objects), I decided to match the amount of objects in the database with the cache size: 5000. Then I started the service tier and opened all pages, reports, XMLPorts etc. I could think of. This resulted in about a 50MB difference in used memory on the server and positively impacted performance by a truckload. I’d advise anyone to try upping this parameter, of course, carefully watching memory load on the server.
  • Data Cache Size: Sets the amount of data cached on the service tier (in-memory). Can be convenient to lower the load on the database server. The standard settings is 9, which equals 512 MB. 8 = 256 MB, 10 = 1024 MB, 11 = 2048 MB etcetera.
  • Compression Threshold: This might be an interesting setting. It determines how much data the service tier will send to the client in one go without compression. By standard, this is set to 64 kilobytes. I didn’t manage to find any information on how this data is structured and how the service tier behaves around this setting: will it prefer sending a compressed dataset that is larger than the screen? Or does it limit the dataset sent to 64 KB even though there’s more records within the filter? It might be worthwhile experimenting with this setting if either your network bandwidth is limited (decrease the threshold) or your processor power on the middle-tier server is limited (increase to make sure the server doesn’t spend valuable time compressing data). Although the environment I’m testing in is not really limiting either way, I am testing if settings 24 and 512 are noticeable on different servicetiers within the same environment.
  • Multiple service tiers: Although I still don’t know where the sweet spot is in the amount of users per service tier, it’s understandable that there ís a sweet spot. I’ve had advice ranging from 25 users all the way up to 100 user per service, and have guesstimated the sweetspot to be about 30 users. This way, all these users will manage to cache all objects in a short time so NAV will “wake-up” quickly in the morning. Multiple services will then make-up for our “manual multi-threading”.

So, how do I balance this load?

Let’s keep it simple: In most environments, setting up different links during client install will divide users over multiple service tiers. Problem solved?
Yes, it does work. However, in case of maintenance or stability problems, it will be difficult to redirect these users to one of the working service tiers. It isn’t flexible!

After searching for days (okay, hours) and not finding anything useful, I decided to give up and see if I could think of a solution myself. What I built is a simple command-line executable launcher that randomly chooses one of the pre-defined servicetiers and then runs NAV with these parameters. Although it’s quick and dirty, it does provide me with basic load balancing, and gives me the flexibility to quickly switch off one of the servicetiers, or even one of the servers. If I know I’ll have to restart a server for maintenance, I’ll modify the settings XML, and then ask users to quit and restart NAV when they prefer, for example anywhere during the next hour. If you’d like to try or use this tool, get it for free here.

Future ideas for this little tool would be to build in true load balancing (checking the database for active sessions per service tier), (de-)activating service tiers from a GUI and – if I figure out a way to do it – switching active users from one service tier to another. Although it’s fun to build, I’d like to know first: Am I the only one running in to this problem? Does anyone have a better solution?

Well, that’s all folks! I hope there’s more info in the NAV community about tuning the three-tier environment – if you find mistakes in my essay, or have any good tips please let me know.

Other Posts

Leave a Reply

Your email address will not be published. Required fields are marked *