GP2013 upgrade from gp10.0 posting is very very slow now

(0) Share

Report

Posted on by Community Member

has anyone had there posting be extremely slow upgrading to GP2013. I'm talking about 6 purchasing batches takes 6 min to post. I made sure the pjournals job is there and running, we have made sure our hardware is up to par. I'm running out of ideas

*This post is locked for comments

I have the same question (0)

All responses (4)

Answers (0)

Jonathan Fear on at

Like (0)

Report

RE: GP2013 upgrade from gp10.0 posting is very very slow now

Did you review the White Paper on Performance Larry? Have you ran a Dexsql.log and seen which calls are taking the longest? How many transactions are in the batches?

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

RE: GP2013 upgrade from gp10.0 posting is very very slow now

Yes I reviewed the whitepaper and there where 7 transactions in the batch and it post fine under my login but some user logins post very slow

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

RE: GP2013 upgrade from gp10.0 posting is very very slow now

Also when we run payroll from a machine in I.T. and from the server the calculate checks portion runs in 12-15 min. If we run from our payroll depts. machine it takes 40-45 min. That machine has the same client as the I.T. machine and server machine.

Was this reply helpful? Yes No
Suggested answer

Redbeard 12,931 on at

Like (0)

Report

RE: GP2013 upgrade from gp10.0 posting is very very slow now

Larry,

You are not alone. The problem is, issues like this are exceedingly rare. I have personally worked with hundreds of clients and have only seen one customer in much the same boat you describe. GP was installed on a Windows 2008 R2 machine and deployed predominately via terminal services - the client had more than 100 users in the system and processed around 3000 online orders in an average week.

First step, ensure you have the implemented the following hot fixes and have installed service packs for W2K8 and SQL Server:

Implemented Windows 2008 R2 Hotfix 2297652 which included the following
http://support.microsoft.com/kb/976700 - http://support.microsoft.com/kb/2155311 - http://support.microsoft.com/kb/979149

You should also disable TCP/IP Chimney on the server. Make sure your antivirus software has an explicit exception for activity on the mdf and ldf (SQL database files) on the server. Check the NIC drivers on the workstation that is under performing. These represent the configuration and patch changes.

The same client also had a number of customizations for processing and reporting purposes. Microsoft recommended a number of modifications to these customizations, like removing non-required OR options from reporting queries, which dropped processing time from 3 minutes to milliseconds.

In the end, we had a Microsoft resource come on site and do a review, after our team and the internal team was unable to figure out how to improve performance. This resulted in a dramatic increase in performance. If I had to put a figure on it, it was 50% configuration and patching of software and 50% modifications to sub-optimally designed custom queries and code running against the GP databases.

I can't imagine this post will provide the impact the site visit from a Microsoft Tech did. My intention is to provide you some information, which may help you achieve the same kind of results we did in this difficult situation.

Was this reply helpful? Yes No