Limits to Epicor - 10,000 ShipTo's or invoices to one CustID?

(Andris Skulte) #1

We’ve got a ‘customer’ that acts a middle-man, and has about 10,000 different ShipTo’s for the true end-customer. The same CustID has about 10,000 invoices in the last 2 years. I’ve seen the slides from Epicor about scalability, and it seems most is geared towards numbers of Epicor user in the system, and didn’t think we’d be hitting the usability limit so soon. Our E10.0.700.4 db is 150gb currently…

I was wondering - what are the other limits we need to consider? Each invoice for this customer takes 1.5-2 minutes to load, so AR brought this up as an issue…

One of our sales associates have thousands of tasks, that caused Epicor to run out of memory, so we switched him to 64 bit (which broke credit card processing), until he clears out the tasks (task module was consuming about 700mb for him). We also use marketing campaign events - 14,000 of them under one campaign, which is also very slow… The rest of Epicor acts normally, with respect to speed.

We’re starting to test the Database Purge and Summarize process, but don’t expect that to help in these cases.

Just wondering what everyone here is seeing, and what guidelines you use. I’m thinking we need to change how we process that customer…

(Bart Elia) #2

Ouch on the 2 minutes. That smells like a missing db index that gets bad due to the number of records. Something to bring up with support to be honest.

As to the size of 150G - we have seen plenty of big systems. I know of over 3 dozen customers with over half a TB, I think the leader is at ~1.6TB. Where the space goes is all over the place. You never know how a business is ran and their needs so we have to review outliers all the time - that’s fine.

Some of the outliers that fly by:
SNTRAN|276,606 – 875 M records!

  • Read through the PDT tool help and test your system.
  • Open a ticket to review the perf issue and PDT results if you don’t see a smoking gun.

We get these ‘missing index’ issues form time to time. That’s why we created the PDT - to package up findings and ease submissions when you have a standard problem or to capture the outliers.

(Andris Skulte) #3

Thanks Bart, We’ll look into running PDT.