Opera 3 SQL SE - Performance issues during payroll update for finance users

alex

Morning all,

I have an issue with a site running Opera 3 SQL SE which I'm hoping someone might be able to give some guidance or ideas on! The site is running Opera 3 SQL SE v2.93.01.

They are a heavy payroll user with approx 4500 employees in one payroll group. When they run the payroll update for this group other users working in finance experience performance issues - slow performance, switch to/retry messages and even crashes. The payroll and finance are in the same company.

The update takes around 2.5 hours to run and due to their processes and time constraints (it is a weekly payroll) they have to run the update during the day on a Thursday. This is causing a lot of complaints from the finance users as they feel the system is unusable during this time.

We recently doubled the RAM in the APP and SQL servers but this did not resolve the issue.

Their system setup is as follows:-

APP Server - Windows 2019 with 64gb RAM

SQL Server - Windows 2019 with 64gb RAM, SQL Server 2019

RDS Servers - Windows 2019 with 32gb RAM. Approx 6-8 users split across two RDS servers. Users on both servers have performance issues.

Performance logs show the APP and SQL servers are busy but not maxed out

Does anyone have any ideas what we can look at next?

Thanks,

Alex

tcyprys

Hi Alex

The only site where I have seen similar SQL SE performance issues, with SQL servers not showing too much in the way of maxing out etc, it turned out to be disk access - don't have too much detail on that as their IT identified this. 

They were running on a server that had numerous instances of SQL on there as well, and the SQL server was separate to the Opera server.

So it was decided to give SQL SE its own VM server, with install of Opera and SQL on the VM server - rather than SQL on a separate server. (not sure if there was another option to solve the issue based on this, but they went down the separate server option as this was the same as their test environment).

This setup has resolved the performance issue. FYI, they had extremely large Nominal, POP and SOP transactions, as opposed to it being Payroll.

The kind of delays before the changes above were typically prefaced by the "Switch to...Retry" message. 

Not sure if that helps, but thought I mention.

Cheers 

Tony