As a business grows and its use of NAV changes, sometimes performance will begin to degrade. This post will briefly describe some activities to undertake when this happens. Please note that this article contains technical language.
SQL server configuration
The resources required for SQL varies depending on the size of the business and its usage of NAV. Performance monitoring tools can be used to determine whether the disks are overloaded, whether RAM is too small to hold all the commonly-used data, whether the CPU is overloaded etc.
If SQL resources are a bottleneck, then sometimes the cheapest resolution to a performance issue is to just provision more.
Maintenance plans are essential in SQL to ensure the database indexes are kept healthy (de-fragmented) and statistics are up to date. We install a standard set of maintenance plans to take care of this when we configure a new SQL server.
Database indexing
Indexing a database correctly is critical. NAV defines very reasonable default indexes to cover standard functionality. However, this won’t be perfect. For instance, in one business it might be important to search or sort on particular fields that another business is not using at all.
Diagnostics tools are available to analyze a database’s execution plan cache and propose changes to indexes based on usage. Introducing an index may speed up a query dramatically, but this needs to be weighed up against the extra IO required to maintain the index. Unused or underutilized indexes can be disabled to save IO resources.
Batch routines
Businesses have the choice of running some NAV functionality throughout the day or in batch mode. Adjust Cost Item Entries and Analysis Views are two examples of this. In our standard setup for NAV implementations, we configure Adjust Cost to run overnight, which speeds the system up a lot when items are being used.
Other batch routines such as order importing, bulk posting, combined invoicing, etc. should all be done after hours if possible, or in quiet periods.
Code review
If other activities don’t yield any performance improvements, it may be necessary to review the code behind the business’s core processes. NAV profiling tools can be used to measure the cost of individual lines of NAV code. Using this technique, we can benchmark the core processes, identify possible areas for improvement and then measure the effect of any changes by re-profiling the code.
Network infrastructure and client deployment method
NAV uses a 3-tier architecture: there is a database server, one or more ‘middle’ tiers and the clients.
It is crucial that the middle tiers (also known as service tiers) have very little latency to the database server.
There are multiple client types. The rich client is an appropriate choice if the latency to the service tier is small and the internet connection is good – upload speed is important for client responsiveness.
For access to NAV from overseas, or over bad internet connections, our clients have had success using the NAV web client. Others ways to tackle this problem are remote desktop, RemoteApp and Citrix.
