ForNAV reports have a very low memory and CPU usage. Based on feedback from customers and partners, report execution is faster than similar reports in RDLC. There are, however, a few scenarios where performance optimization could be needed.
In this article, we cover some common areas where you can improve the performance of your ForNAV reports in Microsoft Dynamics 365 Business Central and Microsoft Dynamics NAV.
On-Premise
When you run ForNAV in an on-premise installation of Business Central or Dynamics NAV, the ForNAV runtime is used on the service tier. Installations that use the Role Tailored Client also use the ForNAV runtime on the client side. The runtime is a simple DLL based on the Microsoft.NET framework.
Virus Scanners
If you run a virus scanner that scans files on demand, then you might see an increase in the time it takes the service tier or the client to load the runtime DLL. A virus scanner typically blocks access to the DLL until it has finished scanning it. Sometimes the scan requires that the files are sent over the Internet for analysis by an online service. This slows down the execution dramatically, also on infrastructure with a fast Internet connection.
As a counter measure to on-demand scanning, ForNAV has placed a digital signature on the runtime, which often increases the trustworthiness of a DLL. Therefore, the need for scanning in an online analysis is decreased.
If you still see a significant use of CPU or network resources when the ForNAV runtime is loaded, then you can try to configure your virus scanner to exclude the DLL from the scan. Most brands of virus scanners can be configured to exclude single files or entire directories.
Automatic Deployment
From Dynamics NAV 2015 and later, the service tier can deploy the add-ins to the Role Tailored Client automatically. This means that the ForNAV runtime DLL is copied to the client on demand. NAV stores the automatically deployed add-ins in the user’s folder for temporary files.
Sometimes, the temporary files are cleaned out and must be deployed again. Normally, this does not take a lot of time and the automatic deployment works smoothly in most installations.
Problems can occur if the network connection between the service tier and the client is a slow connection.
A common pitfall with the automatic deployment is related to the way NAV decides which files to deploy. When a particular Microsoft.NET component is used in the code, the service tier will scan the server’s add-ins folder and subfolders for this DLL. When it finds the right DLL in the right version, then it deploys the DLL and ALL other files in the same folder and subfolders. This means that if you have multiple versions of ForNAV on your server and you store all the DLL files in the same folder, then it copies all the files to the client. Therefore, you must have the different versions of ForNAV in individual subfolders that only contain that one file (DLL).
You can try to copy the ForNAV runtime DLL to the client’s add-ins folder. This disables the automatic deployment for this particular DLL. When the client finds the DLL in the local add-ins folder, it will not ask the service tier for it.
If the automatic deployment is causing a problem, then the symptom is normally that the performance is slow when the first ForNAV report is run by the user.
Default Printer
When a ForNAV report is run, it asks the printer for information about paper size and hardware margins, paper trays, and other device properties. The printer name is determined by the printer selection table or the user’s default printer name, if nothing is found in the printer selection table. This means that the ForNAV runtime often tries to determine the name of the default printer and asks that printer for information.
If the selected printer name is pointing to a network printer, there could be a significant delay while trying to read the device information. Even worse, if the printer in the printer selection table is not accessible to the client that tries to reach it, then you will have to wait for a network timeout to occur before the system can determine if it should try the default printer instead.
Printer information is cached by ForNAV and therefore the symptom of this type of problem is that the first ForNAV report execution is slow.
Terminal Server and Citrix
The use of an RDP client with Terminal Server or Citrix is widely used for deployment of the Role Tailored Client. In many ways, it makes a lot of sense to either facilitate a remote desktop session or a remote application via these platforms. However, in a setup with RDP, the server and client can potentially still share a slow network connection and the automatic deployment can be slow. In this case, the remedy is simple because you only have to copy the ForNAV runtime DLL to one shared NAV client add-ins folder.
Citrix and Terminal Server often clear the user’s temporary files folder when the session ends. Therefore, it triggers the automatic deployment every time the user logs on and establishes a new session.
Another common problem related to Terminal Server and Citrix is that user’s local printers are redirected to the RDP session, so that you can print to your local printer. The redirected printer feature is great, but the redirected printers are slow because of the added network overhead when you try to read their device properties. This means that if the printer selected by the printer selection table, or your default printer, is a redirected printer, then you might experience a drop in performance when the report is starting up.
Furthermore, some Terminal Server and Citrix installations have contradicting information in the registry about default printer setup. In the history of Windows, there have been different ways of specifying the default printer and especially RDP sessions can have this problem.
In order to diagnose and resolve problems with RDP sessions, it is recommended that you try to specify a locally installed virtual printer as your default printer or set it up in the printer selection table.
External HTML Resources
Since the introduction of support for HTML content in text boxes and labels, we have seen performance issues when the HTML code refers to image resources from external locations. For every image used there is a request over the Internet to load that image. Both transfer times and response times from the host will affect the report performance.
Therefore, we recommend that you limit the use of images and place them on a server close to the service tier. Alternatively, you can embed the images in the HTML code, but this can be a bit complex.
The ForNAV runtime will actually cache a number of images from external resources to help overcome this problem. However, the caching is limited and you should still take this into considerations when designing your report.
Recommendations
In general, we suggest that you try a few things if your reports are running slowly:
- Try to set up a virtual printer that is local to the client in the printer selection table or as a default printer for the specific client. Typically, a PDF or XPS printer is available to test this.
- Copy the ForNAV runtime DLL to the client’s add-ins folder, so that the automatic deployment will not kick in.
- After copying the DLL to the local client add-ins folder, you can disable the on-access virus scan of the add-ins folder on the service tier and client.
- Limit the use of external resources in HTML content.
- Try to upgrade your report to the newest version of the ForNAV runtime. If you are struggling with problems on an older version of the runtime then there is a good chance that these issues are fixed in a newer version. You only have to upgrade one report to test the new version of ForNAV. Different versions of ForNAV can run side-by-side on the service tier. Read more about upgrading ForNAV reports here: https://www.fornav.com/knowledge-base/upgrade-fornav-version/
