Dynamics 365 F&O/AX Dynamics 365 CE / CRM Dynamics GP Business Central / NAV UG Dynamics SL Power Platform Fabric UG MS Copilot UG

[Chris Gatin]

After our upgrade, users are advising that they are noticing a slower response time in 2016, to open the application after entering their password on the Welcome Screen and then choosing the company on the Company Log in Screen.   From there the time to open the application for processing is taking longer in 2016 then it did in 2013. 

As well once the application is opened, if the user changes from one company to another again there is a slower response time in 2016 then 2013 to fresh the application to the new company.

Does anyone have any suggestions on what may be causing this? 

——————————
Chris Gatin

——————————

[Adam Warfel]

We recently made the update and are experiencing the same issues as well.  We have yet to determine it the delays are caused by the update to 2016 or another update we recently had to our virtual environment. Some users are experiencing delays of as much as a couple minutes when they switch between entities.

——————————
Adam Warfel
Synergent
Portland ME
————————————————————————-

[Beat Bucher]

Hi Chris,

I encountered some similar behavior last year when we upgraded from GP2010 to 2013… However, after extensive testing, I couldn’t rule out GP was the culprit and it looked like more of an infrastructure issue (our servers are all virtualized, but I have no control on it.. can only lookup the stats and performance in VMWare).

When I test upgraded another system to GP 2016 recently, I didn’t saw any issues with the starting performance compared to 2013 or 2015..

My initial session launch (on the server) the 1st time in the morning is typically a little longer, but avergare around 60-70 secs to a full start until the home screen in GP is loaded (we have a lot of modules, up to 27 loaded in DYNAMICS.SET). Both 2013R2 & 2016 are similar, and I use the ‘remember user’ option, so I don’t have to type a passwd.

The second launch is much faster and typically averages around 20-30 secs. I timed the start to complete in 2016 in less than 20 secs (with both options checked to remember user & cpny). It took exactly 26 secs for GP2013R2, and this could be explained by the fact that the database was on a remote server, whereas for 2016 it was local. I redid the same test for 2013R2 with the local client on the DB server, and timed 23 secs. from start to ready (auto-login & company selected).

Check the HW specs of your system, 2016 might be little more demanding. My 2 tests systems are similar, but my 2013R2 box has 12GB of RAM, and my 2016 Test box has only 8GB. Both SQL servers are 2012.

Hope this helps.

——————————
Beat Bucher
Business Analyst, Dynamics GP MVP
Ultra-Electronics Forensic Technology Inc.
Montreal QC/Canada
+1-514-489-4267
@GP_Beat http://dyngpbeat.wordpress.com/
Montreal QC GPUG Chapter Leader
GP2013R2 / MR2012 CU14
————————————————————————-

[Beat Bucher]

wanted to add some more observations :

In my Prod environment, I timed the full start of the 2013R2 client running off a Win2012 Terminal server at typically 30-35 secs and a company switch around 25 secs.. Considering the overhead of the TS session handling, I believe that those are fairly good values.

My local GP client running off Win10, takes for a full start about 25 secs too, and more or less the same for a company switch.

PS: my user account in GP is PowerUser… so it bypasses the security validation completely, which may have an adverse effect depending on how your user security is loaded.

PPS: One way to tackle security issues is to use GP PowerTools.. see my blog post related to this : https://dyngpbeat.wordpress.com/2013/10/07/use-the-support-debugging-tool-to-tackle-gp-security-issues/

——————————
Beat Bucher
Business Analyst, Dynamics GP MVP
Ultra-Electronics Forensic Technology Inc.
Montreal QC/Canada
+1-514-489-4267
@GP_Beat http://dyngpbeat.wordpress.com/
Montreal QC GPUG Chapter Leader
GP2013R2 / MR2012 CU14
————————————————————————-

[Blair Christensen]

We just tried upgrading from SQL Server 2010 to 2014 and noticed a HUGE performance hit against one of our applications even though not a line of code changed.  We spent two weeks trying to figure out what was going on.  Finally, we set the compatibility level on the database back to 2010 and voila – everything worked performantly.  We found a few obscure Microsoft references that said that they did something to the engine in 2014 and that “some” applications might see serious performance degradation (yeah, no kidding), but didn’t give any suggestions as to root cause or remediation.  It takes a reboot, but it might be worth looking at.

Other items that your DBA should also be looking at are:

• physical hard drive space
• temp db size and usage
• scheduled jobs
• client-side temp location and usage

——————————
Blair Christensen
Database Administrator
Oppenheimer Companies, Inc.
Boise ID
————————————————————————-

[Rachel Cilli]

Our performance speed has taken a HUGE hit, it takes nearly 3 minutes for a full login to GP 2016 R2 for us now from our local workstations, but when I am in GP remotely it is less than 60 seconds.  We also experience a lag in opening SmartList, running reports, and even our postings are interrupted more than they used to be.  We too upgraded from SQL 2012 to 2014 but the biggest thing we changed was we moved our db to Azure.  Our remote location is also in Azure, so I’m thinking we’ll probably need to look at those settings first.

Does anyone else have their connection going back to Azure?  What kind of experiences have you had?

——————————
Rachel Cilli
Financial Systems Analyst
Global LT, Inc.
Troy MI
——————————
——————————————-

[Thomas Garcia]

Hi all. 

Did is not see it mentioned, but anyone using Mekorma needs to get the latest version of their products. Mekorma was found to be the issue at one of my clients and they produced a hotfix at the time. Depending on which Mekorma products you use (and which ones you don’t) you may en able to disable some functions and that will defintitely speed up the login process. 

Hope it helps!

——————————
Thomas Garcia
ICON Business Consulting, LLC | Cooper City FL
ICON, SRL | Santiago, Dominican Republic
954-804-2140
——————————
——————————————-

[Beat Bucher]

Hi Rachel,
Have you checked out this document ? it may help identify a bottleneck :

http://www.encorebusiness.com/app/uploads/2014/03/MDGP_WhitePaper_Performance-3.pdf

Encorebusiness		remove preview
View this on Encorebusiness >

——————————
Beat Bucher
Business Analyst, Dynamics GP MVP
Ultra-Electronics Forensic Technology Inc.
Montreal QC/Canada
@GP_Beat http://dyngpbeat.wordpress.com/
Montreal QC GPUG Chapter Leader
GP2013R2 / MR2012 CU14
——————————
——————————————-

[David Clayton]

Hi Rachel,

How are you connecting to your GP server?  Are you using remote desktop, the GP web client or the regular GP client?

——————————
David Clayton
DMC Consultants Limited
Kingston, Jamaica
http://www.dmcjm.com
——————————
——————————————-

[Rachel Cilli]

Hi David,

From the workstations we use the regular GP Client.  When logging in remotely we use Remote Desktop.

——————————
Rachel Cilli
Financial Systems Analyst
Global LT, Inc.
Troy MI
——————————
——————————————-

[Beth Burrell]

?Before doing anything, can you try running the client from the GP server if it is installed?   If you have the same results, it is NOT infrastructure unless your SQL box is in a different location.  

If it runs fine on the GP SERVER, then it is Infrastructure. 

I would start with this basic troubleshooting technique to make sure you are on the right path.

Just my 2 Cents

——————————
Beth Burrell
CRM Customer Success Coach
Tribridge
Tampa FL
——————————
——————————————-

[Windi Epperson]

Chris,
A couple of thoughts on this. First, we recommend to our customers to turn OFF Connect on the homepage.  It seems to bog things down trying to stream new information.

Second, the specs set on the system requirements for RAM are really low.  Last time I looked it was something like 2 GB for workstations and 4 GB for the server.  Our experience is that workstations should have at least 4GB RAM and 8GB is preferred.  The server should have at least 8GB RAM and 16 or more is preferred. 

If you’re running MR on the same server as GP, you should review those specs as well – MR requires a ton of RAM on top of what is recommended for GP.  So MR and GP on one server should probably have 32 GB RAM.

We’ve definitely seen performance increase with extra RAM.
Thanks
Windi

——————————
Windi Epperson
President/GP Senior Consultant
Advanced Integrators, Inc.
Norman OK
405-946-1774 Ext 102
——————————
——————————————-