Performance with Microsoft Dynamics GP: Where do I Start?

Good day! The intent of this blog post is to tackle something that we get many requests for on the Microsoft Dynamics GP Support Team. This topic is one of the most broad topics that we have to cover in Support. It’s also one of the questions I get asked the most about at the various conferences I have attended over the past few years. Performance issues vary greatly in how they choose to present themselves, but the request is always the same, “it should be fast, but it’s slow/crashing/hanging/dragging.”

First thing: make sure you’ve fully read the Performance White Paper, and gone through the detailed steps. The Performance White Paper is incredibly intensive, in-depth, and kept up to date with all relevant performance tuning information we come across. It covers basic deployments to complex ones, and contains many links to additional tools and documentation.

Please note that our handling of Performance issues as Support Cases is limited. We are more than happy to assist with what we can within reason on Performance issues, but there’s a very fine line between a workable performance case, and a broad performance case. If the performance issue is related to a single task in Microsoft Dynamics GP, such as the Customer look-up taking too long, then we will absolutely assist with an issue like that. There’s plenty to look into if we can reproduce the slowness on demand and it’s only affecting a single area. Our teams are experienced in this area, as this is something we get asked a lot.

Where the difficulty begins is when slowness is affecting multiple areas within the Microsoft Dynamics GP application. If it’s truly isolated, we can target a single support case for each issue, but this almost always points to some kind of network issue. If the slowness occurs everywhere except for when you launch Microsoft Dynamics GP directly on the SQL server, then you have a network issue, or some kind of SQL communication issue. If a case gets to this point, then we will assist up to proving that there is a network issue, and hopefully provide you with information on how to proceed on your own with the resolution. Depending on the environment, it may not be possible to do anything other than proving that the network is the issue. Another difficulty lies with issues that are intermittent. If we can’t capture the error happening, then there’s usually nothing we can do except wait for it to happen again and gather more information each time. Sometimes this requires running extensive logs, but sometimes logging just isn’t available for this type of scenario.

• In tackling a performance problem, the very first thing you should question and focus on is: “Does the environment really meet the System Requirements, and are users adhering to best practice?” System Requirements are covered by the Directory, and our blog covers best practice information. We keep these locations up to date as quickly as we can, and we feature blog posts on high case volume topics, year end procedures and tips, upgrading, etc.

• Review the network requirements that must be in place before installing Microsoft Dynamics GP. 

      •  Information on SQL connectivity errors with Microsoft Dynamics GP can be found in this blog. 

• The Microsoft Dynamics GP Directory is our most up to date location for published system requirements, technical information, downloads, and documentation.

• The Microsoft Dynamics GP Support and Services blog is your most up to date location for best practice, known issues, troubleshooting, how-to’s, and optimization information.

https://community.dynamics.com/gp/b/dynamicsgp

• The next thing to find out with a performance issue is narrowing down the issue, and pinning down exactly what is slow, hanging, or crashing. If you can reproduce the issue on demand, then you’re halfway there. If you are not able to reproduce the issue, then you start with capturing the who, when, what, where, and how information about the occurrences. Start tracking problem reports. Sooner or later, a pattern will emerge. The more specific you can be, then the easier it is to plan what troubleshooting or logging needs to be ran. It’s impossible to troubleshoot just based on “it’s slow.” Performance issue take a lot of work from all parties involved to resolve.

Here’s a small collection of tips and tricks I’ve come across in working various performance cases.

• If you’re facing poor transactional performance on SQL 2014, try changing database compatibility mode to 2012 and test.

• If you’re accessing GP via RemoteApp, Citrix XenApp, or Remote Desktop, be aware that if you enable printer redirection on the session and the network connection to the printer drops, GP may hang or crash when you try to post or print. Try disabling the Session Options such as local printing, clipboard sharing, drive redirection, etc. to see if performance improves.

• If you can narrow down a specific query in SQL that’s slow, the Query Performance Analyzer is a powerful tool that we’ve seen fantastic results from.

• Install GP directly on the SQL server and compare performance from there. This helps rule out whether it’s network slowness or transaction (SQL) slowness.

• Wireshark or NetMon can be used to track packet loss/resubmission, timings, and it even has fancy graphs to plot network congestion times in correlation with GP errors/hangs.

• If it’s isolated to a workstation, don’t forget to test the NIC, cables, wall jacks, etc..

• If the issue occurs semi-frequently but non-reproducible, check for conflicting tasks and watch server load for auto updates, programs with schedules, etc..

• Performance Monitor is a fantastic tool for tracking daily performance of a workstation to see if the user is experiencing system limitations.

• Windows Performance Analyzer can track a crashing process down to the very thread that is causing it, all in a very easy to use interface.

Something else that we see a lot of in support cases opened around performance is skewed baseline metrics. A very common phrase we hear is something along the lines of “well, on GP 10 this used to be fast. The only thing that upgraded was GP and now it’s running slow.” Using an old version of GP is not an fair baseline for performance metrics against new versions of GP. New features, new code, code changes, bug fixes, etc., can all cause newer versions of GP to behave differently; whether that be slower or faster. Major versions of GP are not, and are not be considered the same application in terms of performance baselines; each one behaves differently due to differing code bases. GP is evolving into a more robust and complex application with new features, we aren't stripping out features on as large a scale as we are adding them. Additionally, GP is nearly never the only thing that changes in an upgrade. OS version, server hardware, virtual technology, SQL Server, SSRS, and networking equipment are some of the other things that almost always change with an upgrade of GP. With a new infrastructure, new baseline metrics must be gathered; in the context of the NEW environment. My preferred way to capture a baseline is to install GP directly on the SQL server with no third party products or customizations, then launch directly from there and test. In a support case, this is what will be used as the baseline for performance issues, not an old version of GP.

Finally, here is my collection of Performance related documentation, covering a range of products. Some of the docs are dated, but the information still applies to the latest versions of Microsoft Dynamics GP as well.

Dynamics GP Hosting Guide:

https://mbs.microsoft.com/customersource/Australia/GP/learning/documentation/white-papers/MSDGPhostingguide

Windows Server 2012 R2 Server Tuning Guide:

https://msdn.microsoft.com/en-us/library/windows/hardware/dn529133(v=vs.85).aspx

Guidance for Dynamics GP with SQL AlwaysOn:

https://mbs.microsoft.com/Files/customer/GP/Downloads/Updates/Microsoft%20Dynamics%20GP%20AlwaysOn.docx

Microsoft SQL Server Performance Monitoring and Tuning Tools:
https://msdn.microsoft.com/en-us/library/ms179428.aspx

https://technet.microsoft.com/en-us/library/ms187830(v=sql.105).aspx

https://technet.microsoft.com/en-us/library/ms188284(v=sql.105).aspx

Using Application Virtualization with Dynamics GP:

https://mbs.microsoft.com/customersource/northamerica/GP/learning/documentation/white-papers/MDGP_WP_Appv

Windows Performance Analyzer:

https://msdn.microsoft.com/en-us/library/windows/hardware/hh448170.aspx