From time to time we get “Epicor is slow” typically from the same few people. We look into it and there is no signs that it is actually slow. I typically check my client and the servers client. I can’t reproduce it. They are always skeptical when say the server seems normal. And they hate the goto “restart your computer option”.
So is there a way to measure or watch the “slowness” coming from a client? I could add a trace flag to the user but I worry it would make the symptoms worse for them. I’m just looking for a way to prove if it is or isn’t the client. I’m just not sure of the best approach.
You should be able to set up trace logs on a per-user level that you can then analyze with the Performance and Diagnostic Tool. This would enable you to see timings.
Are they using the native client or something such as RDP?
Wierd Story:
Customer was complaining that “Certain users” had slow response, but other users didn’t. This was being experienced in MES Screens… First thought “Hardware” or “Network”… but then had the user come up into the office and log in… turned out their slowness came with them.
THEN they told me “Last time this happened, we gave the user a new MES User ID, and the problem went away for about a month, until it started getting slow again”…
“Wait” i said…
I quickly figured out… the user had not CLOCKED OUT of MES for over a month… this particular user had started/ended production for 1000s of jobs.
As soon as we clocked out “for the day” (which was over a month of work)… the user’s response time was amazing.
In addition to this, they had another 30 shop users with the same problem (not quite as extreme). When we clocked all of them off and on again, their system sped up even more.
So I actually decided to install the Performance and Diagnostics Tool on the client (In my head I thought it could be only used on the server). I’m not sure why I didn’t think to do that first. It has a Network Diagnostics option in which you point it to a sysconfig file and it will run a test, saving up to 20 results. So after doing that, it showed it wasn’t having network issues, at least for the zTable BO. I can’t say if other BOs would be the same. I’m going to let the user trace run for the day and take a look at it after that.
You can also look in System Monitor with “Display All Tasks” selected under the Actions Menu, and review if anyone was running something more intensive on server processors. Processes like MRP, and various Financial Reports/Processes can have an impact - especially with some of the Month End procedures.
Our hardware that we installed E10 on is pretty robust, and we have much better performance than we did in our E9 environment. Our controller used to wait until the weekend to run some of her Month-End processes; and I always process MRP so that it’s completed before our users start logging in to Epicor (for the length of time our MRP process runs, I scheduled it at 4:00 am).
Large volumes of invoices can also have an impact when the invoice group is being posted.
If it’s a server side process causing delays I would expect all users to complain of slowness. But, would be something to check.
Epicor can be resource intensive depending on user count, number of jobs/quotes, invoices, running processes, etc. We’ve got powerful servers running our E10 infrastructure. So it’s not been an issue for us. But if you have lightweight servers running E10 it could be.
Thanks everyone. After looking at some client log files, I still didn’t get a definitive answer that points to one thing or another. We did adjust our appserver recycle time to before the user gets into work.(We had it set at 7am, we moved to early in the morning) The user does a lot of work with Jobs(Job Entry, Job Manager) so I think when it was recycling, it would temporary be “slow” and from then on, the perception is it’s slow.
The client trace log didn’t have any consistent data that showed it was slow. And to be clear on what the definition of slow is for the user, it is when the cursor turns to the spinner(aka the whirlygig).
So I’m confident, it’s not the server. I wonder if there is way to analyze how the form performs after it’s made the server call? I feel the data is getting there in a timely manor but the form is waiting on something to display it, whether that be the Epicor application or another application that is causing it to wait.
It is/was to fix a memory problem that would occur from time to time. Mostly likely caused by one of my naively written customizations in conjunction with nightly MRP. It was easier at the time to schedule the recycle. And like everybody else, in my “free” time I’ll see if I can find the root problem.(I have hunch where it is coming)
I personally like the idea of giving it it’s morning shower/coffee after it’s nightly MRP run but again that’s probably because I’m naive.
LOL - I think it’s six one, half a dozen the other on recycling on a set schedule. We don’t have a schedule. The app pools just get recycled when I’m doing maintenance. Sometimes that’s once a week and sometimes it’s several weeks apart. I think it’s just preference and your environment.
We have developed an Auto-ClockOut customization that prevents this situation and also makes the Approval process for supervisors much simpler.
Basically, it works like this:
We have two shifts with the second shift ending at 11pm. At 11:55pm, an SSRS report is run and distributed to all supervisors listing employees still clocked in with their active details.
At 11:57pm, a dummy report that is scheduled in Epicor runs. A Data Directive BPM that looks at the SysRptLst table runs and conditionally detects that this report has been run. Embedded C# code in the BPM uses Epicor BOs to “End Activity” (if there are any still active) and then clock each employee out.
The C# code also includes complete logging of all Auto-ClockOut activity and e-mails Epicor Admins reminding them to check this log file. We have been running this for over a year and have found that it is very effective.
