You’re offline. This is a read only version of the page.
364
Client is running GP2016 16.00.0741 - GP is taking a long time to load - I do not see any thing in the DYNAMICS SET file that would be causing this but when I ran a DEX SQL Log I noticed there was a big jump with nothing there between 16:52:35 and 16:53:04 - I am not the best at reading DEXSQL Logs but that seems odd to me there is nothing there in that 29 seconds
/* Date: 04/21/2021 Time: 16:52:35
stmt(178169504):*/
{ CALL DYNAMICS.dbo.zDP_SY10500SS_1 ( 'sa', 1, 'POWERUSER' ) }
/* Date: 04/21/2021 Time: 16:52:35
stmt(178168600):*/
{CALL PHARM.dbo.zDP_ReportPublishersF_1('sa',-32768,-32768,'','','sa',32767,32767,'ÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞ','ÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞÞ')}
/* Date: 04/21/2021 Time: 16:53:04
stmt(178165888):*/
{CALL DYNAMICS.dbo.zDP_SY30000F_1('sa',0,-2147483648,'sa',0,2147483647)}
Great!
MEM is an add-on that handles multiple companies or entities within a single GP Database, and depending on how big your organization is setup in GP, that might add some delay while MEM is scouring through all the data.. though 2 minutes seems a little too much to me. Make sure you have the latest build of MEM for your GP version installed.
Hi,
To add to what other already reported, the fundamental way to debug GP performances is to install a bare bone GP client on the server, with no customizations and then time the startup (up to login screen) and the login time. All-in-all, you should be able to get into the GP Home page within 30 secs without any add-ons and customizations loaded.
Adding ISV products immediately adds some delay, based on the type of add-on, as some of them are loading additional libraries for the product to work, and/or often time "call home" to check for updates, which in some cases can time out after a lengthy delay (which usually can't be set, but can often be disabled).
An average configured GP client with a few ISV's and reports customizations loads generally within 45-60 secs.
Along with what David mentioned, I'll say that the zDP_ReportPublishersF_1 commonly shows up in the log as taking a long time, but almost never the actual cause, as you mentioned as well.
With performance cases, the first thing we usually recommend is to test with Dynamics GP directly on the SQL Server itself to see if GP still takes a long time to load or not. If it doesn't, then that usually rules out GP and signals more a network related issue.
Another test is, if the forms and/or reports dictionary files are on a shared network directory, try moving them local, i.e. C:\Program Files (x86)\Microsoft Dynamics\GP2016R2\Data\, for example would be a default location, change the Dynamics.set to point to those files local, then see if the application still takes a long time to load or not.
Next, would be removing third-party products and/or customizations from the equation. You can do this on one of the machines that has GP on it, by having all users log out, then rename the GP directory, then in Control Panel > Programs and Features, right-click on the GP application, choose 'Change', then run a Repair, which will re-create the entire GP directory including folders and files, but without any third party products/customizations nor forms/reports dictionary files. Use this 'new' GP directory to launch the application and see if it still takes a long time to load or not.
--If it doesn't, then we'd test with the forms/reports dictionary files, then third party products/customizations, adding them back one by one, testing after each one, until the performance hit returns, identifying the potential cause.
We've also seen where going through other technologies, such as Citrix, for example, can also cause behavior with Dynamics GP that we don't normally see otherwise, so we' like to rule those out as well, having the users test just using remote desktop to connect to a server or workstation, if not physically logging onto the machine.
Once you identify the potential cause of the performance hit, you can focus more in that area.
The following document also has information that may help:
docs.microsoft.com/.../mdgp2010_whitepaper_performance
Thanks
Howdy
The DEXSQL.LOG only shows the communication between the Dexterity runtime engine (Dynamics.exe) and the SQL Server.
It will not show anything happening purely at the Dexterity level or pauses caused by network connectivity issues.
GP Power Tools (previously known as the MBS Support Debugging Tool) has the ability to capture Dexterity Script Logs and Dexterity Script Profile during startup and login as well as the DEXSQL.LOG.
These logs will actually show us where the performance is being lost. Once installed the setting is at the bottom of the first tab on the Dex.ini Settings window.
Please have a look at the benefits presentation, GPPT portal and product page:
www.winthropdc.com/.../GPPowerTools_Benefits.ppsx
www.winthropdc.com/products_GPPT.htm
Regards
David
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,253
Super User 2024 Season 2
#2
Martin Dráb
230,188
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (