NAV Server Performance Test

An active session is a connection to the Microsoft Dynamics NAV Server instance from a Microsoft Dynamics NAV client, such as the Microsoft Dynamics NAV Windows client or Microsoft Dynamics NAV Web client, NAS, or Web services.

This measure is a good indicator of the current session load on the NAV server.

An operation is a call to the Microsoft Dynamics NAV Server instance from a Microsoft Dynamics NAV client to run Microsoft Dynamics NAV objects.

OData and SOAP requests are not included in the value of this measure.

A high value or a consistent increase in the value of this measure is a definite sign of a processing bottleneck on the server.

Microsoft Dynamics NAV supports deployments where several different companies access a centrally maintained Microsoft Dynamics NAV application. By using this multitenancy support, you can add new customers to your solution easily, and you can roll out updates quickly with limited downtime for your customers.

A tenant is an entity that uses your solution and stores data in a business database. This is often either a business or a group of legal entities whose data can be stored in one database. In practical terms, a tenant is a database that stores business data for one or more Microsoft Dynamics NAV companies. Each tenant is connected to a Microsoft Dynamics NAV Server instance, but the Microsoft Dynamics NAV Server instance can support multiple tenants.

A high value for this measure is a cause for concern, as it indicates that many queries were re-executed. This can in turn can delay request processing by the NAV server.

Every 30 seconds, the Microsoft Dynamics NAV Server instance writes a record to indicate that the instance is "alive”. If the NAV server takes too much time to perform this write operation, it indicates a highly latent network connection between the server and the SQL database. Such a slow network connection can also significantly delay NAV server operations.  

The preferred connection cache contains connections from the SQL connection pool that was last used by a Microsoft Dynamics NAV user.

This measure indicates the percentage of requests for SQL connections that were serviced by the connections already present in the preferred connection cache.

A high value is desired for this measure as it means that connection requests were serviced by the cache itself, and not by the SQL connection pool. This indicates that the NAV server was able to connect to the SQL database server quickly.

The calculated fields cache contains the results of the CALCFIELDS Function (Record) calls. The CALCFIELDS Function calculates the FlowFields in a record. FlowFields are virtual fields. The values in these fields are not saved in the table. This means that you must use either the CALCFIELDS function or the SETAUTOCALCFIELDS Function (Record) to update them. For example, if you retrieve a record using the FIND Function (Record) and NEXT Function (Record), the FlowFields in those records are set to zero (0). Then, when you call CALCFIELDS, their values are updated.

A high value for this measure implies that a large number of requests for FlowFields were serviced by the calculated fields cache itself, thus minimizing direct database accesses and related overheads. A high value is hence desired for this measure.

A low value on the other hand means that the database had to be accessed to service a majority of requests for FlowFields.  This can happen even the calculated fields cache does not have enough space to hold on to the results of the CALCFIELDS Function (Record) calls. You may have to size the cache right to avoid this.

The command cache contains the results of all SQL commands.

If the results of a SQL command are available in the commands cache, then a query need not retrieve the same by directly accessing the database. This significantly improves database performance, as it greatly reduces expensive database accesses. This is why, the value of this measure should ideally be high.

A low value on the other hand implies that many requests did not find their results in the command cache, and were hence forced to access the database for the same. This can happen if the command cache is not sized right, and is hence not able to store many SQL command results. If this is so, then you may want to consider fine-tuning the cache size.

The primary key cache contains the results of requests to get a record by using its primary key.

A high value for this measure indicates that many queries that use the primary key for retrieving records are being serviced by the primary key cache itself, and are not being sent to the database for processing. As this reduces expensive database accesses, it is good practice to keep the value of this measure high.

A low value for this measure on the other hand implies that a majority of such queries are being processed in the SQL database only, as the primary key cache does not have the desired results. This could be because enough memory has not been assigned to the cache. You may want to consider resizing the cache for better results.

The result set cache contains result sets that are returned from SQL Server.

A well-sized result set cache can significantly improve database performance by reducing direct database accesses for servicing requests. In this case, the value of this measure will be high.

A low value on the other hand could imply that the cache is badly sized, rendering it unable to handle requests. This is bound to have an adverse impact on database health, as it means that requests are accessing the database often for result sets.