GP 2013 performance issues client to server

(0) Share

Report

Posted on by Rob Klaproth

1,730

One of our clients is having issues with processing speed when doing payroll runs. It doesn't matter how large or small the batch is, a check run with 2 checks can get stuck, or one with 500. This happens whether physical checks or DD batches.

It only happens at the workstation level. If I give them access to the GP SQL server, and they login and run payroll from there using their normal GP id, it works flawlessly and much faster (4-5x!!)..

We have eliminated pretty much anything to do with SQL itself, done lots of performance tuning and ran through the Microsoft whitepaper on GP performance, checking off every item on Microsoft's list.

The desktops are Windows 7 Zendesk, which is basically a VM residing on the SAME HOST as the GP SQL server, so we have also ruled out network as an issue given they are on the same host, they aren't even hitting the router or switch to the best of my knowledge...

I'm at a loss, not really sure what else to look for, but if you have any ideas, please do let me know what we might check. They are using Mekorma to print checks, but given that the issue doesn't happen on the server which also has Mekorma installed, and we've also ran through all the motions with Mekorma support, I don't think that is the issue.

They are on GP2013 SP2 (NOT R2).

*This post is locked for comments

All responses (6)

Answers (0)

Richard Wheeler 75,848 Moderator on at

Like (0)

Report

RE: GP 2013 performance issues client to server

Years ago I would occasionally see issues like this. One thing that sometimes would help was to change the version of the SQL client being used in the ODBC administrator. To be honest with you I never did truly understand why choosing an older SQL client would improve the situation but it did.
Rob Klaproth 1,730 on at

Like (0)

Report

RE: GP 2013 performance issues client to server

Originally they were not on the same host so we moved one of them to the same host and the same virtual switch just to rule that out as a possibility. Pings are generally 1ms or better, although some occasional jumps to 10ms, as high as 30ms for 1 or 2 pings if you let it run continuously for 20 or 30 minutes.

It's worth looking into some more on the networking side for sure, but their network guys looked at everything, shrugged their shoulders and said "looks good" LOL
KirkLivermont 5,985 on at

Like (0)

Report

RE: GP 2013 performance issues client to server

Harry,

No wit intended, just pointing to where I would look next. Your posts are normally much more informative than mine so please keep at it.

Regards,

Kirk
Redbeard 12,931 on at

Like (0)

Report

RE: GP 2013 performance issues client to server

Kirk - it seems brevity is the soul of wit after all.
Suggested answer

Redbeard 12,931 on at

Like (0)

Report

RE: GP 2013 performance issues client to server

Rob,

If users on the SQL server enjoy better performance, then I would suspect a network variable is your root cause. Many moons ago, I might have suggested you add a host file to the workstation to translate the SQL Server's name into it's IP address - old school. With virtual machines, and virtual network adapters being involved you might want to spend some time working that angle. Considering the exhaustive troubleshooting you've already undertaken, I would punt to another group of nerds (VM Specialists).
Suggested answer

KirkLivermont 5,985 on at

Like (0)

Report

RE: GP 2013 performance issues client to server

Hi Rob,

This might be a shot in the dark but if the VMs reside on the same host have you looked into the virtual switch configuration between the two VMs?

Regards,

Kirk