The primary complaint about Epicor(we’re running 10.2.400 on prem), is that it’s slow. It’s to the point our engineering team won’t use the system unless they have to, or they go out of there way to design webpages by querying(read only) the SQL DB directly as it’s significantly faster than the client to access the information. I’ve run the PDT tool and we are passing performance benchmarks, but I do notice we’re “marginally” passing the SQL Query Test. The screenshot below it completed in ~3 sec which is the fastest I’ve seen. We’re generally right around 3.5 sec(the threshold). Keep in mind we ~8-10 users on the system usually for context. In practice for a snappy system what is “good” performance for the SQL Query Test(I think Haso told me he sees around 2 seconds…)?
You mentionned a PDT tool…(what the acronym means) .I am unaware of such a tool… Is it something I can run? From which menu ? or it is only our CAM that can run it ?
Pierre
Pierre, the tool is distributed with your install media if I am not mistaken.
you should find it on your app server and then you can install it on your client to run from there.
I do not know if it is still there in Kinetic, but I assume it is?
https://epiccare.epicor.com/epiccare?id=epiccare_kb_article&sys_id=db1a04e01b4219582ed6cb36624bcbd4
KB0038815
Nice Alisa!
It is, but you should grab the newer EpicWeb copy. Sometimes the version that ships with the software has issues.
Completely unsurprised at the crickets as to the original question - are there any Epicor customers anywhere who would call their system snappy? 
It depends…
The users’ disposition has been snappy at times… 
Pierre is on cloud if I recall, so the PDT should mean nothing to him.
I think you can still use PDT from your workstation to measure network performance even if you’re cloud. Not sure.
Just ran PDT and scored 2,000 on that test. This is a SQL test, so the most relevant part of the system would be BAQ’s and Retrieve buttons…and those are responsive.
Where the system seems to bog down is in the client UI and some of the biz-logic heavy posting processes. I lack the time and background to diagnose the causes of that, but I doubt it’s data retrieval that’s causing issues.
Thanks! This is helpful as we are working through the server sizing guide to ensure we are meeting minimum specs with a goal of reaching “reasonably good performance”. In this case it sounds like 2 seconds is an attainable goal for us to shoot for!
FYI, if engineers are complaining, try looking at the # of records in the erp.ECO tables. Epicor keeps a copy of each revision checked out and in (per ECO group). It’s kind of a half-assed revision history that only works (sorta) if you cut a new ECO group per change order. Our engineers pretty much set up 1 ECO group per engineer, and over time all those revs resulted in millions of rows in those tables. It also caused massive load times in Engineering Workbench since the system was retrieving tens of thousands of records (or more) every time the user entered their group.
I told them they could avoid this if they would periodically close their old ECO group and start a new one, but I couldn’t get compliance. However, coincidentally, I had (per a customer req) enforced an actual rev control system (in short, the system locked revs once checked in, checking out again would create a new rev) I hit up Epicor for a data fix (FX_Del_ECORev_byGroup) that would clear the cruft.
Workbench has been mostly butter (as butter as any client screen gets) since.
Thanks everyone! For historical reference, if someone else is reading this thread thinking the same thing… Our Engineers don’t use Eng Workbench or ECOs, they will often do simple things like:
-Check how many of a given product we’ve shipped.
-Check a BOM to verify materials are accurate.
-Lookup customer purchase history and RMA history.
It’s not any one screen that is slow. It’s the time it takes to login, open a screen, enter the data and get the results vs developing a webpage with read only SQL access. I don’t have numbers in front of me, but it’s probably around 5-10x longer for them to use the client to get the data vs accessing a webpage (which can be developed in a couple hours). Please note I understand the downside being security, and technical debt, but it’s not my decision… Kind of funny but I’m realizing this explanation indicates it’s not our DB that is slow(webpages and client access the same DB) which is what I’m looking to optimize…
I think Kinetic is javascript based, so I think Epicor is heading the direction our engineers are trying to go now on 10.2.400. Hopefully that means we’ll have a more responsive web based client…
JavaScript can get big and take time to load, but it’s always up-to-date (no upgrades to clients), it’s more secure than hitting the database directly, and I’ve found the browser more performant than the rich client.
Is there a PDT for Epicor 11 (Kinetic)? On Epicweb I searched and the result was for Epicor 10. I don’t have a utilities folder in my client install, as directed to in https://epiccare.epicor.com/epiccare?id=epiccare_kb_article&sys_id=KB0029091
That is a poorly worded sentence. The client is needed to run the tests, but not where the install is. PDT is on the server where the deployment folder is.
This is mine for 11.1.200
